Solución 1:
OpenVPN sobre TLS
Su VPN está utilizando TCP como protocolo de transporte. La instancia de stunnel se usa para encapsular el contenido de la secuencia TCP en TLS/TCP. Obtienes esta pila de protocolos:
[IP ]<------------------------>[IP ]
[OpenVPN]<------------------------>[OpenVPN]
[TLS ]<~~~~~>[TLS]
[TCP ]<->[TCP ]<----->[TCP]<->[TCP ]
[IP ]<->[IP ]<----->[IP ]<->[IP ]
[ ] [ ] [ ] [ ]
Server stunnel stunnel Client
Entre las instancias de stunnel, tiene esta pila de protocolos en el cable:
[IP ] [OpenVPN ] [TLS ] [TCP(443)] [IP ] [... ]
A medida que TLS cifra su carga útil, un atacante solo puede ver:
[??? ] [TLS ] [TCP(443)] [IP ] [... ]
Así que sí, es tráfico TLS simple (podría ser HTTP/TLS, SMTP/TLS, POP/TLS o cualquier otra cosa para alguien que observa el tráfico, pero se parece mucho a HTTP/TLS ya que se usa el puerto TCP 443). Puede verificar esto usando wireshark:registre el tráfico entre las instancias de stunnel. En la interfaz de usuario de wireshark (botón derecho en un paquete de la transmisión), puede pedirle a wireshark que interprete el tráfico como TLS:lo reconocerá como tráfico TLS (verá los diferentes mensajes TLS pero no la carga útil de la sesión TLS) .
Es posible que desee utilizar SNI en el cliente para parecerse a lo que haría un navegador moderno. Es posible que desee usar ALPN también, pero Stunnel actualmente no maneja eso.
OpenVPN con TLS integrado
En comparación, si usa OpenVPN, tendrá algo como esto:
[IP ] [OpenVPN ] [TCP ] [IP ] [... ]
Que se parece a esto:
[??? ] [OpenVPN ] [TCP ] [IP ] [... ]
La capa TLS integrada no encapsula los paquetes (IP, Ethernet), sino que solo se utiliza para configurar la sesión y autenticar:
[TLS ] [OpenVPN ] [TCP ] [IP ] [... ]
En este caso, su tráfico no parece un tráfico TLS simple, pero obviamente es OpenVPN. Si interpreta este tráfico como OpenVPN en wireshark, reconocerá los mensajes de OpenVPN y dentro de ellos los mensajes TLS (pero no la carga útil).
Advertencia
Debe tener en cuenta que si un atacante pasivo no puede darse cuenta de que su servidor remoto es de hecho un servidor OpenVPN, un atacante activo podrá averiguarlo:simplemente conectándose a su servidor a través de TLS, podrá para confirmar que no un servidor HTTP/TLS. Al tratar de hablar el protocolo OpenVPN, podrá detectar que su servidor es un servidor OpenVPN/TLS.
OpenVPN sobre TLS con autenticación de cliente
Si le preocupa esto, podría habilitar la autenticación de cliente TLS:un atacante no podrá iniciar una sesión TLS en funcionamiento y no podrá adivinar qué carga útil está encapsulada a través de TLS.
*Advertencia:** No me refiero a la compatibilidad con TLS integrada en OpenVPN (consulte más arriba una explicación sobre por qué no le ayudará).
OpenVPN/TLS y HTTP/TLS multiplexados
Otra solución es servir HTTP y OpenVPN a través de la sesión TLS. sslh se puede usar para detectar automáticamente la carga útil del protocolo y enviarlo a un servidor HTTP/TCP simple o a su servidor OpenVPN/TCP. El servidor se verá como un servidor HTTP/TLS estándar, pero alguien que intente hablar OpenVPN/TLS con este servidor podrá detectar que, de hecho, también es un servidor 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 sobre HTTP CONNECT sobre TLS
Otra solución es usar un servidor HTTP/TLS estándar y usar HTTP CONNECT/TLS para conectarse al servidor OpenVPN:se verá como un servidor HTTP estándar. Incluso puede solicitar la autenticación del cliente para autorizar la solicitud HTTP CONNECT (squid debería poder hacer esto).
OpenVPN tiene una opción para usar un Proxy HTTP:
http-proxy proxy.example.com
Debería poder combinar esto con una instancia de stunnel que se conecta a un PROXY HTTPS remoto:
http-proxy 127.0.0.1 8443
remote vpn.example.com
Que implementaría esta pila de protocolos:
[IP ]<------------------------>[IP ]
[OpenVPN]<------------------------>[OpenVPN]
[HTTP ]<------------->[HTTP ]
[TLS ]<~~~~~>[TLS]
[TCP ]<->[TCP ]<----->[TCP]<->[TCP ]
[IP ]<->[IP ]<----->[IP ]<->[IP ]
[ ] [ ] [ ] [ ]
Server HTTPS PROXY stunnel Client
Solución 2:
La respuesta de ysdx es excelente y describe muy bien cómo se verá el tráfico en el cable.
Sin embargo, no se menciona que el análisis del tráfico puede ser de gran ayuda para identificar aplicaciones.
Supongamos que su conexión OpenVPN parece una conexión https en el cable, por lo que un atacante no puede leer el flujo de bytes y saber qué tipo de conexión es.
Una conexión https típica no vivirá demasiado tiempo. Tal vez su navegador mantiene una conexión abierta con su servidor de correo, no lo sé. Sin embargo, en general, habrá muchas conexiones relativamente cortas a muchos servidores remotos diversos.
OTOH, la conexión OpenVPN puede durar horas o días, y enviará una gran cantidad de datos de ida y vuelta al servidor openvpn.
Puede mitigar la conexión de larga duración interrumpiendo y reiniciando periódicamente la conexión. Esto presumiblemente tiene implicaciones para el tráfico de su aplicación, pero podría funcionar. Sin embargo, el patrón de mucho tráfico entre usted y el servidor openvpn será mucho más difícil de camuflar.