Solution 1 :
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 ]
[ ] [ ] [ ] [ ]
Server 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 chiffre sa charge utile, un attaquant ne peut voir que :
[??? ] [TLS ] [TCP(443)] [IP ] [... ]
Alors oui, c'est du trafic TLS simple (il peut s'agir de HTTP/TLS, SMTP/TLS, POP/TLS ou de n'importe quoi d'autre pour quelqu'un qui regarde le trafic, mais cela ressemble beaucoup à HTTP/TLS car le port TCP 443 est utilisé). Vous pouvez vérifier cela en utilisant wireshark :enregistrer le trafic entre les instances stunnel. Dans l'interface utilisateur 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 voudrez peut-être également utiliser ALPN, mais stunnel ne le gère pas actuellement.
OpenVPN avec TLS intégré
En comparaison, si vous utilisez OpenVPN, vous aurez quelque chose comme ça :
[IP ] [OpenVPN ] [TCP ] [IP ] [... ]
Qui ressemble à ceci :
[??? ] [OpenVPN ] [TCP ] [IP ] [... ]
La couche TLS intégrée n'encapsule pas les paquets (IP, Ethernet) mais n'est utilisée que pour configurer la session et s'authentifier :
[TLS ] [OpenVPN ] [TCP ] [IP ] [... ]
Dans ce cas, votre trafic pas ressemble à un trafic TLS simple 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
Sachez que si un attaquant passif ne pourra pas dire que votre serveur distant est en fait un serveur OpenVPN, un attaquant actif pourra le découvrir :simplement en se connectant à votre serveur via TLS, il pourra pour confirmer que ce n'est pas 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 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 sur les raisons pour lesquelles cela ne vous aidera pas).
OpenVPN/TLS et HTTP/TLS multiplexés
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 soit à un serveur HTTP/TCP ordinaire, soit à votre serveur OpenVPN/TCP. Le serveur ressemblera à un serveur HTTP/TLS standard, mais quelqu'un essayant de parler OpenVPN/TLS avec ce serveur pourra détecter qu'il s'agit également d'un serveur OpenVPN/TLS.
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 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 :cela ressemblera à un serveur HTTP standard. Vous pouvez même exiger l'authentification du client afin d'autoriser la requête HTTP CONNECT (squid devrait pouvoir le faire).
OpenVPN a la possibilité d'utiliser un proxy HTTP :
http-proxy proxy.example.com
Vous devriez pouvoir combiner cela 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 ]
[ ] [ ] [ ] [ ]
Server HTTPS PROXY stunnel Client
Solution 2 :
La réponse de ysdx est excellente et décrit très bien à quoi ressemblera le trafic sur le fil.
Toutefois, il n'est pas mentionné que l'analyse du trafic peut contribuer grandement à l'identification des applications.
Supposons que votre connexion OpenVPN ressemble à une connexion https sur le câble, de sorte qu'un attaquant ne puisse pas lire le flux d'octets et savoir de quel type de connexion il s'agit.
Une connexion https typique ne vivra pas trop longtemps. Peut-être que votre navigateur maintient une connexion ouverte avec votre serveur de messagerie, je ne sais pas. En général cependant, il y aura beaucoup de connexions relativement courtes vers de nombreux serveurs distants divers.
OTOH, la connexion OpenVPN peut durer des heures ou des jours et enverra beaucoup de données dans les deux sens au serveur openvpn.
Vous pouvez atténuer la connexion de longue durée en supprimant et en redémarrant périodiquement la connexion. Cela a vraisemblablement des implications pour le trafic de votre application, mais cela pourrait être réalisable. Cependant, le modèle de beaucoup et beaucoup de trafic entre vous et le serveur openvpn va être beaucoup plus difficile à camoufler.