stunnel le trafic vpn et assurez-vous qu'il ressemble au trafic SSL sur le port 443

J'essaie de rendre mon trafic sortant et entrant aussi légitime que possible au plus près du trafic SSL. Existe-t-il un moyen de DPI mon propre trafic pour s'assurer qu'il ressemble au trafic SSL et non au trafic OpenVPN? Et sur la base de ma configuration de configuration, tout le trafic utilise-t-il le port 443, qui est le port SSL?

Ma configuration est la suivante:

STUNNEL sur ordinateur portable:

[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 SUR ordinateur portable:

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

CONFIGURATION STUNNEL SUR SERVEUR:

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 sur le serveur:

local REMOTE_SERVER_IP
port 11440
proto tcp

OpenVPN sur TLS

Votre VPN utilise TCP comme protocole de transport. L'instance stunnel est utilisée pour encapsuler le contenu du flux TCP dans TLS / TCP. Vous obtenez cette pile de protocoles:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Serveur stunnel stunnel Client

Entre les instances stunnel, vous avez cette pile de protocoles sur le fil:

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

Comme le TLS crypte sa charge utile, un attaquant ne peut voir que:

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

Alors oui, c'est du trafic TLS (il peut s'agir de HTTP / TLS, SMTP / TLS, POP / TLS ou de toute autre chose pour quelqu'un qui regarde le trafic, mais cela ressemble beaucoup à HTTP / TLS car le port TCP 443 est utilisé). Vous pouvez le vérifier en utilisant WireShark: enregistrez le trafic entre les instances Stunnel. Dans l'interface de Wireshark (bouton droit sur un paquet du flux), vous pouvez demander à Wireshark d'interpréter le trafic comme TLS: il le reconnaîtra comme du trafic TLS (vous verrez les différents messages TLS mais pas la charge utile de la session TLS) .

Vous voudrez peut-être utiliser SNI dans le client afin de ressembler à ce que ferait un navigateur moderne. Vous pouvez utiliser ALPN aussi bien , mais stunnel actuellement ne gère pas.

OpenVPN avec TLS intégré

En comparaison, si vous utilisez OpenVPN, vous aurez quelque chose comme ceci:

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

Qui ressemble à ceci:

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

La couche TLS intégrée n'encapsule pas les paquets (IP, Ethernet) mais est uniquement utilisée pour configurer la session et authentifier:

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

Dans ce cas, votre trafic ne ressemble pas à un trafic TLS ordinaire mais est évidemment OpenVPN. Si vous interprétez ce trafic comme OpenVPN dans Wireshark, vous reconnaîtrez les messages OpenVPN et à l'intérieur d'eux les messages TLS (mais pas la charge utile).

avertissement

Vous devez savoir que si un attaquant passif ne peut pas dire que votre serveur distant est en fait un serveur OpenVPN, un attaquant actif pourra le savoir: simplement en se connectant à votre serveur via TLS, il pourra pour confirmer qu'il ne s'agit pas d' un serveur HTTP / TLS. En essayant de parler le protocole OpenVPN, il pourra détecter que votre serveur est un serveur OpenVPN / TLS.

OpenVPN sur TLS avec authentification client

Si cela vous inquiète, vous pouvez activer l'authentification du client TLS: un attaquant ne pourra pas lancer une session TLS fonctionnelle et ne pourra pas deviner quelle charge utile est encapsulée sur TLS.

* Avertissement: ** Je ne parle pas de la prise en charge TLS intégrée dans OpenVPN (voir ci-dessus pour une explication des raisons pour lesquelles cela ne vous aidera pas).

OpenVPN / TLS multiplexé et HTTP / TLS

Une autre solution consiste à servir à la fois HTTP et OpenVPN sur la session TLS. sslh peut être utilisé pour détecter automatiquement la charge utile du protocole et l'envoyer à un serveur HTTP / TCP standard ou à votre serveur OpenVPN / TCP. Le serveur ressemblera à un serveur HTTP / TLS standard mais une personne essayant de parler OpenVPN / TLS avec ce serveur pourra également détecter qu'il s'agit en fait d'un serveur OpenVPN / TLS.

        soit OpenVPN / TCP
          ou HTTP / TCP       
[1].---------. .------. HTTP / TCP .-------------.
-> | stunnel | ----> | sslh | -------> | Serveur HTTP |
   '---------' '------' | «-------------»
                           | .----------------.
                           «------> | Serveur OpenVPN |
                        OpenVPN / TCP '----------------'

[1] = Soit OpenVPN / TLS / TCP ou HTTP / TLS / TCP

OpenVPN sur HTTP CONNECT sur TLS

Une autre solution consiste à utiliser un serveur HTTP / TLS standard et à utiliser HTTP CONNECT / TLS pour se connecter au serveur OpenVPN: il ressemblera à un serveur HTTP standard. Vous pouvez même exiger une authentification du client afin d'autoriser la requête HTTP CONNECT (squid devrait pouvoir le faire).

OpenVPN a une option pour utiliser un proxy HTTP:

http-proxy proxy.example.com

Vous devriez pouvoir combiner ceci avec une instance stunnel se connectant à un proxy HTTPS distant:

http-proxy 127.0.0.1 8443
remote vpn.example.com

Qui implémenterait cette pile de protocoles:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [HTTP] <-------------> [HTTP]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Serveur HTTPS PROXY stunnel Client

La réponse de ysdx est excellente et décrit très bien à quoi ressemblera le trafic sur le câble.

Cependant, sans mention, l'analyse du trafic peut grandement contribuer à l'identification des applications.

Supposons que votre connexion OpenVPN ressemble à une connexion https sur le câble, donc un attaquant ne peut pas lire le flux d'octets et savoir de quel type de connexion il s'agit.

Une connexion https typique ne durera pas trop longtemps. Peut-être que votre navigateur maintient une connexion ouverte à votre serveur de messagerie, je ne sais pas. En général, cependant, il y aura beaucoup de connexions relativement courtes à de nombreux serveurs distants divers.

OTOH, la connexion OpenVPN peut vivre pendant des heures ou des jours, et enverra beaucoup de données dans les deux sens au serveur openvpn.

Vous pouvez atténuer la connexion à long terme en supprimant et en redémarrant régulièrement la connexion. Cela a probablement des implications sur le trafic de votre application, mais peut être réalisable. Le schéma de beaucoup et beaucoup de trafic entre vous et le serveur openvpn, cependant, sera beaucoup plus difficile à camoufler.