TLS viaja dentro del canal de control, no por todo el túnel

Ver la palabra TLS en la descripción de una VPN y concluir que un proxy web entenderá el tráfico es un atajo habitual. Dentro de este protocolo los pares intercambian sus propios paquetes, y TLS funciona como parte de un canal dentro de ese intercambio. La carga útil que importa al usuario viaja en un formato de mensaje distinto, y por eso los dos nunca coinciden con una sesión HTTPS ordinaria.

El sobre llega primero

Cada paquete del túnel empieza con la cabecera propia del protocolo: un tipo de mensaje, un identificador de clave y, sobre un transporte de flujo de bytes, un prefijo de longitud que marca dónde termina el paquete. Un lector que no analiza ese sobre no puede saber dónde empieza el campo siguiente.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Ese esquema es un mapa y no una tabla de bytes, porque los campos exactos dependen del tipo de mensaje, aunque el primer octeto siempre empaqueta el opcode y el identificador de clave juntos. Adivinar el tipo de mensaje por el número de puerto es como los decodificadores acaban etiquetando mal lo que ven. El orden es lo que importa para el diagnóstico: transporte, luego el sobre del protocolo, luego uno de dos tipos de trabajo. Lee el sobre antes de formarte cualquier opinión sobre lo que sigue. Un decodificador que empieza en el lugar equivocado produce disparates con mucha confianza.

La capa de fiabilidad pertenece al protocolo

Los mensajes de control necesitan una entrega ordenada y confirmada, y el protocolo lo proporciona él mismo con confirmaciones y retransmisiones. Una confirmación puede llegar como mensaje propio o viajar con otro mensaje de control, lo que hace que las trazas parezcan irregulares a quien espera un intercambio limpio.

La ventaja es que el handshake de TLS recibe un portador fiable incluso cuando el transporte exterior es UDP. El coste es que un solo datagrama puede contener solo parte de esa conversación, así que tratarlo como un registro TLS autónomo produce disparates. El reensamblado tiene que ocurrir en la capa del protocolo. Por eso un paquete capturado rara vez parece un paso completo del handshake.

Cambiar el transporte exterior a TCP no elimina esta capa. Un transporte fiable significa menos retransmisiones a nivel de protocolo, no que desaparezca el enmarcado ni que el tráfico se convierta en HTTP.

Los paquetes de datos usan un formato distinto

Una vez existe la sesión, la carga útil llega como mensajes de datos que transportan paquetes IP internos o tramas Ethernet. Están protegidos con sus propias claves y su propio procesamiento, y no son registros de aplicación TLS en ningún sentido que aceptaría una biblioteca TLS.

Esa separación es visible en la configuración: el canal de control y el canal de datos tienen ajustes de cifrado separados, así que una línea de registro que nombra uno no dice nada del otro. Leer un cifrado de control fuerte como prueba de un cifrado de datos fuerte es un error de informe habitual.

Mantén también fuera de la explicación una idea equivocada relacionada. TLS no es un canal de clave pública junto a un canal de datos simétrico, porque TLS mismo protege sus registros de forma simétrica una vez establecidas las claves. La distinción real es el rol y el formato del paquete, no qué tipo de criptografía usa cada lado.

Por qué un proxy HTTPS no puede ayudar

Un proxy que termina TLS espera un flujo de registros TLS y luego un protocolo de aplicación dentro de él. El canal de control de este protocolo se transporta dentro de su propio enmarcado con una capa de fiabilidad alrededor, así que un proxy que termina lee ese enmarcado como entrada corrupta.

Un reenviador transparente que deja pasar bytes o datagramas sin interpretarlos puede funcionar, siempre que no reescriba ni reensamble el flujo. La pregunta que hay que hacer sobre cualquier intermediario es si reenvía el transporte y el enmarcado reales, no si admite TLS en algún sitio. Pregúntalo antes de pasar una noche con reglas de proxy. La mayoría de los fallos aquí son arquitectónicos y no un ajuste que falta.

Leer una traza correctamente

Espera primero un intercambio de control, luego un número mucho mayor de mensajes de datos, ambos compartiendo un transporte. Si la fase de control se completa y la fase de datos se atasca, el fallo afecta a claves, enrutamiento o filtrado de la ruta de datos y no al handshake. Captura unos cuantos mensajes de datos y comprueba si salen del cliente. Esa sola observación parte la búsqueda por la mitad.

Las descripciones históricas de los métodos de clave en la documentación del protocolo no implican que una versión determinada siga admitiendo todos los formatos antiguos. Comprueba la versión que ejecutas antes de construir una expectativa sobre un párrafo que describe cómo funcionaban las cosas antes.