Hay algunas cosas para entender.

La primera es que la mayoría de las herramientas de VPN se diseñaron originalmente para proporcionar conectividad privada a través de redes que eran inseguras, posiblemente natted o con firewall pero no hostiles activamente a las VPN.

La segunda es que TLS tradicional es un contenedor sobre TCP. TCP es una mala elección para las VPN porque sufre de "bloqueo de cabecera de línea". Si un paquete se pierde, todos los datos detrás de él se bloquean hasta que se retransmiten con éxito. Esto solía causar grandes problemas al ejecutar VPN a través de TCP, es un problema menor ahora que tenemos una retransmisión rápida de TCP, pero aún así no es lo ideal.

El tercero es que la inspección profunda de paquetes es algo bastante nuevo. Las redes que pasarán el tráfico TLS legítimo sin ser molestadas pero que no pasarán otro tráfico en el puerto 443 siguen siendo la excepción, no la regla.

Si bien Openvpn tiene una opción TCP, está diseñado principalmente para ejecutarse sobre UDP. Utiliza TLS para el intercambio de claves, pero cifra los paquetes de red reales utilizando un sistema diseñado explícitamente para ese propósito.

enlace

  

Alguien también debería decir algo sobre DTLS (TLS sobre UDP)

DTLS es un protcol bastante nuevo. No veo ninguna razón por la que no puedas / no debas construir una solución de VPN, pero supongo que los proveedores de software de VPN no están especialmente de humor para rediseñar su software.

En cualquier caso, no ayudaría con el escenario descrito en la pregunta.

Versión corta:

• Los protocolos VPN deben proporcionar una encapsulación que TLS no proporciona
• ¡Por supuesto, es posible hacer un túnel VPN sobre TLS para obtener el mismo efecto!

Versión larga:

El nombre Virtual Private Network sugiere la respuesta a su pregunta. Un verdadero protocolo VPN emula una red, lo que implica la capacidad de enrutar múltiples tipos de tráfico y puertos simultáneamente a través de un solo canal. Es por eso que con un protocolo VPN como IPSec puede terminar, por ejemplo, paquetes TCP encapsulados dentro de paquetes ESP encapsulados dentro de otros paquetes TCP. (Consulte también ¿Cuál es la diferencia entre SSH e IPsec? )

Por defecto, TLS no proporciona esta capacidad. TLS toma bytes, los cifra y los transfiere al destinatario que puede descifrarlos. Eso es; Todo lo que se debe hacer tiene que ser hecho por la aplicación. Bajo HTTPS, un servidor web y un cliente intercambian bytes de datos HTTP a través de un canal TLS. Bajo IMAPS, un servidor de correo y un cliente intercambian bytes de datos IMAP a través de un canal TLS.

Para tener conectividad genérica de "Red" a través de TLS, necesita un cliente y un servidor que puedan hacer esa encapsulación y desencapsulación en cualquiera de los extremos. No lo obtienes gratis.

Eso no quiere decir que no pueda tener una VPN que se ejecute sobre TLS. Hay muchos productos que lo hacen; incluso los proveedores principales como Checkpoint son compatibles con VPN basadas en IPSec y TLS. En algunos casos, el TLS simplemente encapsula los datagramas IPSec, por lo que la "N" real es a través de IPSec, pero el TLS lo obtiene a través de Internet.

Tenga en cuenta que, en algunos casos, un adversario sofisticado puede inferir cuándo se utiliza una conexión TLS para VPN según el patrón de comunicación. ¡La seguridad operacional es más que cifrar bits!

Muchos protocolos VPN do usan TLS. En particular, casi todas las modernas VPN cliente-servidor (por ejemplo, utilizadas para conectar una computadora portátil de forma remota a una red corporativa) admiten TLS como transporte primario o alternativo.

Soy un colaborador del conocido cliente de código abierto para las VPN basadas en TLS / SSL: openconnect . Ingresé el protocolo VPN de GlobalProtect (TLS + ESP) casi completamente por mi cuenta. He estudiado suficientes protocolos VPN en detalle para observar algunos patrones bastante claros y compromisos de diseño.

Ventajas de TLS para la autenticación y transporte VPN:

• Robustez. El tráfico VPN basado en TLS es indistinguible del tráfico HTTPS "normal" en términos de su estructura de paquetes y contenido cifrado, aunque la sincronización y el tamaño de los paquetes, y la duración de las conexiones, sugieren que está transportando algo diferente al tráfico de navegador "normal". La universalidad de HTTPS significa que las VPN basadas en TLS pueden pasar a través de casi todos los firewalls y middleboxes; Sólo los censores realmente determinados que realizan análisis de tráfico o los puntos finales de VPN de la lista negra por DNS o IP pueden bloquearlo.
• Garantías de seguridad sólidas: el moderno TLSv1.2 (pronto, 1.3) es un protocolo muy bien diseñado, cuidadosamente analizado y de maduración gradual para comunicaciones seguras. Muchas bibliotecas lo envuelven de una manera que hace que sea bastante difícil de usar mal. Si usa una VPN basada en TLS, puede esperar que su conexión a la puerta de enlace use cifrados modernos (no 1DES antiguo, por ejemplo) y la verificación de la clave pública de la puerta de enlace x509, lo que limita los ataques de intermediario. Es posible arruinar la implementación de TLS, rompiendo gravemente su seguridad, pero relativamente difícil debido a la estandarización de bibliotecas de alta calidad que hacen la mayoría de los bits difíciles. Sería mucho más fácil escribir una VPN insegura basada en un protocolo "personalizado".

Desventajas de TLS para VPN transporte , en comparación con ESP (la capa de transporte normal de IPSEC- VPNs basadas):

• TLS normalmente se ejecuta sobre TCP, que funciona mal como un transporte de túnel con condiciones de red subyacentes congestionadas o con pérdida ... especialmente en el caso de TCP sobre TCP .
• Afortunadamente, DTLS ("datagrama TLS") puede aliviar esto; se utiliza principalmente en el protocolo VPN AnyConnect / openconnect, así como en los protocolos de comunicaciones en tiempo real como WebRTC.
• La mayoría de los sistemas operativos modernos tienen soporte optimizado en el núcleo para IPSEC y ESP. Esto hace que ESP sea realmente eficiente y de bajo costo para los gateways y firewalls y sistemas de cliente final, cuando se implementa correctamente. Normalmente, TLS se implementa en el espacio de usuario y, combinado con la complejidad de la secuencia TCP subyacente, hace que sea menos eficiente.
• (Una implementación en el kernel igualmente eficiente de D TLS debería ser posible, pero no tengo conocimiento de ninguno en un sistema operativo convencional.)

... ¿en cuanto a usar TLS para la autenticación / configuración de una VPN? Básicamente no veo desventajas reales allí, aparte de la falta de un protocolo estandarizado para ello.

TLS es más flexible, ampliamente implementado y más fácil de depurar que ISAKMP (el componente de autenticación / intercambio de claves de IPSEC) . Varios protocolos VPN corporativos modernos, incluido GlobalProtect, utilizan TLS para la autenticación y el intercambio de claves pero luego ESP para el transporte de datos (aunque pueden recurrir a TLS si es necesario). Esta es una combinación bastante efectiva y eficiente, en mi experiencia.