Lösung 1:
OpenVPN über TLS
Ihr VPN verwendet TCP als Transportprotokoll. Die Stunnel-Instanz wird verwendet, um den Inhalt des TCP-Streams in TLS/TCP zu kapseln. Sie erhalten diesen Protokollstapel:
[IP ]<------------------------>[IP ]
[OpenVPN]<------------------------>[OpenVPN]
[TLS ]<~~~~~>[TLS]
[TCP ]<->[TCP ]<----->[TCP]<->[TCP ]
[IP ]<->[IP ]<----->[IP ]<->[IP ]
[ ] [ ] [ ] [ ]
Server stunnel stunnel Client
Zwischen den Stunnel-Instanzen haben Sie diesen Protokollstapel auf dem Draht:
[IP ] [OpenVPN ] [TLS ] [TCP(443)] [IP ] [... ]
Während das TLS seine Nutzlast verschlüsselt, kann ein Angreifer nur sehen:
[??? ] [TLS ] [TCP(443)] [IP ] [... ]
Also ja, es handelt sich um einfachen TLS-Verkehr (es könnte HTTP/TLS, SMTP/TLS, POP/TLS oder irgendetwas anderes für jemanden sein, der sich den Verkehr ansieht, aber es sieht sehr nach HTTP/TLS aus, da der TCP-Port 443 verwendet wird). Sie können dies mit Wireshark überprüfen:Zeichnen Sie den Datenverkehr zwischen den Stunnel-Instanzen auf. In der Wireshark-Benutzeroberfläche (rechte Schaltfläche auf einem Paket des Streams) können Sie Wireshark bitten, den Datenverkehr als TLS zu interpretieren:Er wird als TLS-Datenverkehr erkannt (Sie sehen die verschiedenen TLS-Nachrichten, aber nicht die Nutzdaten der TLS-Sitzung). .
Möglicherweise möchten Sie SNI im Client verwenden, um so auszusehen, wie es ein moderner Browser tun würde. Vielleicht möchten Sie auch ALPN verwenden, aber Stunnel unterstützt das derzeit nicht.
OpenVPN mit eingebautem TLS
Wenn Sie im Vergleich dazu OpenVPN verwenden, sehen Sie in etwa so aus:
[IP ] [OpenVPN ] [TCP ] [IP ] [... ]
Das sieht so aus:
[??? ] [OpenVPN ] [TCP ] [IP ] [... ]
Die eingebaute TLS-Schicht kapselt die (IP-, Ethernet-)Pakete nicht, sondern wird nur zum Aufbau der Sitzung und Authentifizierung verwendet:
[TLS ] [OpenVPN ] [TCP ] [IP ] [... ]
In diesem Fall tut Ihr Datenverkehr nicht sieht aus wie ein einfacher TLS-Verkehr, ist aber offensichtlich OpenVPN. Wenn Sie diesen Datenverkehr in Wireshark als OpenVPN interpretieren, erkennen Sie die OpenVPN-Nachrichten und darin die TLS-Nachrichten (aber nicht die Payload).
Warnung
Sie sollten sich bewusst sein, dass, wenn ein passiver Angreifer nicht erkennen kann, dass Ihr Remote-Server tatsächlich ein OpenVPN-Server ist, ein aktiver Angreifer dies herausfinden kann:indem er sich einfach über TLS mit Ihrem Server verbindet, wird er dazu in der Lage sein um zu bestätigen, dass dies nicht ist ein HTTP/TLS-Server. Indem er versucht, das OpenVPN-Protokoll zu sprechen, kann er erkennen, dass Ihr Server ein OpenVPN/TLS-Server ist.
OpenVPN über TLS mit Client-Authentifizierung
Wenn Sie sich darüber Sorgen machen, können Sie die TLS-Client-Authentifizierung aktivieren:Ein Angreifer kann keine funktionierende TLS-Sitzung initiieren und nicht erraten, welche Nutzlast über TLS gekapselt ist.
*Warnung:** Ich spreche nicht von der eingebauten TLS-Unterstützung in OpenVPN (siehe oben für eine Erklärung, warum es Ihnen nicht hilft).
Multiplexed OpenVPN/TLS und HTTP/TLS
Eine andere Lösung besteht darin, sowohl HTTP als auch OpenVPN über die TLS-Sitzung bereitzustellen. sslh kann verwendet werden, um die Nutzlast des Protokolls automatisch zu erkennen und entweder an einen einfachen HTTP/TCP-Server oder Ihren OpenVPN/TCP-Server zu senden. Der Server sieht aus wie ein Standard-HTTP/TLS-Server, aber jemand, der versucht, OpenVPN/TLS mit diesem Server zu sprechen, kann erkennen, dass es sich tatsächlich auch um einen OpenVPN/TLS-Server handelt.
either OpenVPN/TCP
or HTTP/TCP
[1].---------. .------.HTTP/TCP.-------------.
-->| stunnel |---->| sslh |------->| HTTP server |
'---------' '------'| '-------------'
| .----------------.
'------>| OpenVPN server |
OpenVPN/TCP'----------------'
[1]= Either OpenVPN/TLS/TCP or HTTP/TLS/TCP
OpenVPN über HTTP CONNECT über TLS
Eine andere Lösung besteht darin, einen Standard-HTTP/TLS-Server zu verwenden und sich mit HTTP CONNECT/TLS mit dem OpenVPN-Server zu verbinden:Er sieht aus wie ein Standard-HTTP-Server. Sie können sogar eine Authentifizierung des Clients verlangen, um die HTTP-CONNECT-Anforderung zu autorisieren (Squid sollte dazu in der Lage sein).
OpenVPN bietet die Möglichkeit, einen HTTP-Proxy zu verwenden:
http-proxy proxy.example.com
Sie sollten dies mit einer Stunnel-Instanz kombinieren können, die eine Verbindung zu einem Remote-HTTPS-PROXY herstellt:
http-proxy 127.0.0.1 8443
remote vpn.example.com
Welche würde diesen Protokollstapel implementieren:
[IP ]<------------------------>[IP ]
[OpenVPN]<------------------------>[OpenVPN]
[HTTP ]<------------->[HTTP ]
[TLS ]<~~~~~>[TLS]
[TCP ]<->[TCP ]<----->[TCP]<->[TCP ]
[IP ]<->[IP ]<----->[IP ]<->[IP ]
[ ] [ ] [ ] [ ]
Server HTTPS PROXY stunnel Client
Lösung 2:
Die Antwort von ysdx ist großartig und beschreibt sehr gut, wie der Datenverkehr auf der Leitung aussehen wird.
Unerwähnt bleibt jedoch, dass die Verkehrsanalyse einen großen Beitrag zur Identifizierung von Anwendungen leisten kann.
Nehmen wir an, Ihre OpenVPN-Verbindung sieht auf der Leitung genauso aus wie eine https-Verbindung, sodass ein Angreifer den Bytestrom nicht lesen und wissen kann, um welche Art von Verbindung es sich handelt.
Eine typische https-Verbindung wird nicht allzu lange leben. Vielleicht hält Ihr Browser eine Verbindung zu Ihrem Mailserver offen, ich weiß es nicht. Im Allgemeinen wird es jedoch viele relativ kurze Verbindungen zu vielen unterschiedlichen Remote-Servern geben.
OTOH, die OpenVPN-Verbindung kann Stunden oder Tage dauern und viele Daten an den OpenVPN-Server hin und her senden.
Sie können die langlebige Verbindung entschärfen, indem Sie die Verbindung regelmäßig trennen und neu starten. Dies hat vermutlich Auswirkungen auf Ihren Anwendungsdatenverkehr, könnte aber praktikabel sein. Das Muster von viel, viel Verkehr, der zwischen Ihnen und dem OpenVPN-Server fließt, wird jedoch viel schwieriger zu tarnen sein.