stunnel vpn tráfico y asegúrese de que se ve como el tráfico SSL en el puerto 443

Estoy tratando de hacer que mi tráfico saliente y entrante se vea lo más legítimo posible. ¿Hay alguna forma de DPI mi propio tráfico para garantizar que se vea como tráfico SSL y no tráfico OpenVPN? Y según mi configuración, ¿todo el tráfico usa el puerto 443, que es el puerto SSL?

Mi configuración es la siguiente:

STUNNEL en la computadora portátil:

[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 EN portátil:

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

CONFIGURACIÓN DE STUNNEL EN EL SERVIDOR:

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 en el servidor:

local REMOTE_SERVER_IP
port 11440
proto tcp

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. Obtiene esta pila de protocolos:

[IP] <------------------------> [IP]
[OpenVPN] <------------------------> [OpenVPN]
            [TLS] <~~~~~> [TLS]
[TCP] <-> [TCP] <-----> [TCP] <-> [TCP]
[IP] <-> [IP] <-----> [IP] <-> [IP]
[] [] [] []
 Servidor stunnel cliente stunnel

Entre las instancias de aturdimiento tiene esta pila de protocolos en el cable:

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

A medida que el TLS cifra su carga útil, un atacante solo puede ver:

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

Entonces, sí, es tráfico TLS simple (podría ser HTTP / TLS, SMTP / TLS, POP / TLS o cualquier otra cosa para alguien que mira el tráfico, pero se parece mucho a HTTP / TLS ya que se usa el puerto TCP 443). Puede verificar esto utilizando wireshark: registre el tráfico entre las instancias de stunnel. En la interfaz de usuario wireshark (botón derecho en un paquete de la secuencia), puede pedirle a Wirehark 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 utilizar ALPN también, pero actualmente Stunnel no maneja eso.

OpenVPN con TLS incorporado

En comparación, si está utilizando OpenVPN, tendrá algo como esto:

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

Que se ve así:

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

La capa TLS integrada no encapsula los paquetes (IP, Ethernet) sino que solo se usa para configurar la sesión y autenticar:

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

En este caso, su tráfico no se ve como 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 podrá decir que su servidor remoto es en realidad un servidor OpenVPN, un atacante activo podrá descubrir esto: simplemente conectándose a su servidor a través de TLS, podrá para confirmar que se trata no de 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 del cliente TLS: un atacante no podrá iniciar una sesión TLS que funcione y no podrá adivinar qué carga útil se encapsula sobre TLS.

* Advertencia: ** No estoy hablando del soporte TLS incorporado en OpenVPN (ver arriba para una explicación sobre por qué no lo ayudará).

OpenVPN / TLS multiplexado y HTTP / TLS

Otra solución es servir tanto HTTP como 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 el 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.

        ya sea OpenVPN / TCP
          o HTTP / TCP       
[1] .---------. .------. HTTP / TCP .-------------.
-> | stunnel | ----> | sslh | -------> | Servidor HTTP |
   '---------' '------' | '-------------'
                           El | .----------------.
                           '------> | Servidor OpenVPN |
                        OpenVPN / TCP '----------------'

[1] = OpenVPN / TLS / TCP o 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 requerir 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 HTTPS PROXY remoto:

http-proxy 127.0.0.1 8443
remote vpn.example.com

Lo que implementaría esta pila de protocolos:

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

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 de tráfico puede recorrer un largo camino hacia la identificación de aplicaciones.

Supongamos que su conexión OpenVPN se parece a 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 típica de https no durará demasiado. Tal vez su navegador mantiene una conexión abierta a 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 vivir durante horas o días, y enviará una gran cantidad de datos al servidor openvpn.

Puede mitigar la conexión de larga duración cayendo y reiniciando periódicamente la conexión. Presumiblemente, esto tiene implicaciones para el tráfico de su aplicación, pero podría ser viable. Sin embargo, el patrón de mucho tráfico entre usted y el servidor openvpn será mucho más difícil de camuflar.