Stunnel VPN-Verkehr und stellen Sie sicher, dass es wie SSL-Verkehr auf Port 443 aussieht

Ich versuche, meinen ausgehenden und eingehenden Datenverkehr so ​​legitim wie möglich für SSL-Datenverkehr zu gestalten. Gibt es eine Möglichkeit, meinen eigenen Datenverkehr zu DPI zu machen, um sicherzustellen, dass er wie SSL-Datenverkehr und nicht wie OpenVPN-Datenverkehr aussieht? Und basierend auf meiner Konfiguration verwendet der gesamte Datenverkehr den Port 443, der der SSL-Port ist?

Meine Konfiguration ist wie folgt:

STUNNEL auf dem Laptop:

[openvpn]
# Set sTunnel to be in client mode (defaults to server)
client = yes  
# Port to locally connect to
accept = 127.0.0.1:1194  
# Remote server for sTunnel to connect to
connect = REMOTE_SERVER_IP:443

OPENVPN CONFIG ON Laptop:

client
dev tun
proto tcp
remote 127.0.0.1 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun

STUNNEL CONFIG ON SERVER:

sslVersion = all
options = NO_SSLv2
;chroot = /var/lib/stunnel4/
; PID is created inside the chroot jail
pid = /stunnel4.pid
; Debugging stuff (may useful for troubleshooting)
 debug = 7
 output = /var/log/stunnel4/stunnel4.log
setuid = root
setgid = root
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
compression = zlib
[openvpn]
accept = REMOTE_SERVER_IP:443
connect = REMOTE_SERVER_IP:11440
cert=/etc/stunnel/server.pem
key=/etc/stunnel/server.key

OPENVPN CONFIG auf dem Server:

local REMOTE_SERVER_IP
port 11440
proto tcp

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 befindet sich dieser Protokollstapel auf der Leitung:

[IP]
[OpenVPN]
[TLS]
[TCP (443)]
[IP]
[...]

Während der TLS seine Nutzdaten verschlüsselt, kann ein Angreifer nur Folgendes sehen:

[??? ]
[TLS]
[TCP (443)]
[IP]
[...]

Also ja, es handelt sich um reinen TLS-Verkehr (es kann sich um HTTP / TLS, SMTP / TLS, POP / TLS oder etwas anderes handeln, wenn jemand den Verkehr betrachtet, aber es ähnelt HTTP / TLS, da der TCP-Port 443 verwendet wird). Sie können dies überprüfen, indem Sie wireshark verwenden: Zeichnen Sie den Verkehr zwischen den Stunnel-Instanzen auf. In der wireshark-Benutzeroberfläche (rechte Taste auf einem Paket des Streams) können Sie wireshark auffordern, den Datenverkehr als TLS zu interpretieren: Er erkennt ihn als TLS-Datenverkehr (Sie sehen die verschiedenen TLS-Nachrichten, aber nicht die Nutzdaten der TLS-Sitzung). .

Möglicherweise möchten Sie SNI im Client verwenden, um das Aussehen eines modernen Browsers zu erhalten. Möglicherweise möchten Sie auch ALPN verwenden, aber stunnel übernimmt dies derzeit nicht.

OpenVPN mit eingebautem TLS

Wenn Sie OpenVPN verwenden, haben Sie im Vergleich dazu ungefähr Folgendes:

[IP]
[OpenVPN]
[TCP]
[IP]
[...]

Welches sieht so aus:

[??? ]
[OpenVPN]
[TCP]
[IP]
[...]

Die eingebaute TLS-Schicht kapselt die (IP-, Ethernet-) Pakete nicht, sondern wird nur zum Einrichten der Sitzung und zur Authentifizierung verwendet:

[TLS]
[OpenVPN]
[TCP]
[IP]
[...]

In diesem Fall sieht Ihr Datenverkehr nicht wie normaler TLS-Datenverkehr aus, sondern ist offensichtlich OpenVPN. Wenn Sie diesen Verkehr in Wireshark als OpenVPN interpretieren, erkennen Sie die OpenVPN-Nachrichten und in ihnen die TLS-Nachrichten (aber nicht die Nutzdaten).

Warnung

Sie sollten sich darüber im Klaren sein, dass ein aktiver Angreifer dies herausfinden kann, wenn ein passiver Angreifer nicht erkennen kann, dass es sich bei Ihrem Remote-Server tatsächlich um einen OpenVPN-Server handelt. Er kann sich einfach über TLS mit Ihrem Server verbinden um zu bestätigen, dass es sich nicht um einen HTTP / TLS-Server handelt. Wenn er versucht, das OpenVPN-Protokoll zu sprechen, erkennt er, dass es sich bei Ihrem Server um einen OpenVPN / TLS-Server handelt.

OpenVPN über TLS mit Clientauthentifizierung

Sie befürchten, dass Sie die TLS-Clientauthentifizierung aktivieren könnten: Ein Angreifer kann keine funktionierende TLS-Sitzung initiieren und nicht erraten, welche Nutzdaten über TLS eingekapselt sind.

* Warnung: ** Ich spreche nicht über die eingebaute 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, HTTP und OpenVPN über die TLS-Sitzung bereitzustellen. Mit sslh kann die Nutzlast des Protokolls automatisch erkannt und entweder an einen einfachen HTTP / TCP-Server oder an Ihren OpenVPN / TCP-Server gesendet werden. 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.

        entweder OpenVPN / TCP
          oder HTTP / TCP       
[1] .---------. .------. HTTP / TCP .-------------.
-> | stunnel | ----> | sslh | -------> | HTTP-Server |
   '---------' '------' | '-------------'
                           | .----------------.
                           '------> | OpenVPN Server |
                        OpenVPN / TCP '----------------'

[1] = Entweder OpenVPN / TLS / TCP oder HTTP / TLS / TCP

OpenVPN über HTTP CONNECT über TLS

Eine andere Lösung besteht darin, einen Standard-HTTP / TLS-Server und HTTP CONNECT / TLS zum Herstellen einer Verbindung mit dem OpenVPN-Server zu verwenden: Es sieht aus wie ein Standard-HTTP-Server. Sie können sogar eine Authentifizierung des Clients anfordern, um die HTTP CONNECT-Anforderung zu autorisieren (dies sollte Squid können).

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

Welches 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

Die Antwort von ysdx ist großartig und beschreibt sehr gut, wie der Verkehr auf dem Kabel 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 genauso aus wie eine https-Verbindung auf der Leitung, sodass ein Angreifer den Byte-Stream 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 verschiedenen Remote-Servern geben.

OTOH, die OpenVPN-Verbindung kann stunden- oder tagelang bestehen und sendet viele Daten hin und her an den openvpn-Server.

Sie können die langlebige Verbindung verringern, indem Sie die Verbindung regelmäßig trennen und neu starten. Dies hat vermutlich Auswirkungen auf Ihren Anwendungsdatenverkehr, ist jedoch möglicherweise praktikabel. Das Muster von vielen, vielen Zugriffen zwischen Ihnen und dem openvpn-Server wird jedoch viel schwerer zu tarnen sein.