TLS 1.3 sigue enviando el nombre del servidor en claro

Actualizar un listener a TLS 1.3 cambia lo que un observador puede leer, pero no tanto como sugiere el número de versión. El ClientHello sigue viajando antes de que se negocie cualquier cifrado, y en una conexión normal el nombre de servidor solicitado está ahí en texto claro. Encrypted Client Hello es el mecanismo que lo oculta, y es un despliegue aparte con sus propios requisitos previos. Ejecute estos cuatro pasos antes de escribir una política que suponga cualquiera de los dos comportamientos.

Qué expone realmente el handshake

TLS 1.3 cifra el certificado del servidor y la mayor parte del handshake que sigue al ServerHello. Todo lo que el cliente envía primero queda fuera de esa protección, porque las claves todavía no existen. La indicación de nombre de servidor forma parte de ese primer vuelo, y por eso un observador pasivo aún puede leerla sin romper nada.

La especificación ECH, RFC 9849, cambia esto al cifrar un ClientHello interno para un servidor que coopera. El handshake externo permanece y lleva un nombre público que la red puede ver, así que el despliegue sigue necesitando una identidad externa que tenga sentido para los intermediarios. Ese nombre externo es la parte que la gente pasa por alto cuando espera que la conexión se vuelva anónima. Es un nombre de cobertura, no un nombre oculto, y tiene que resolverse y autenticarse como cualquier otro.

Nada de esto oculta la ruta de entrega. Las direcciones de origen y destino, los puertos, los tamaños de paquete y los tiempos siguen siendo observables, y a menudo dicen más sobre quién habla que el nombre. La resolución de nombres y las relaciones a nivel de aplicación son otra capa más, cada una con su propia visibilidad.

Leer un ClientHello en lugar de suponer

La versión en el ServerHello no le dice qué envió el cliente. Mire el primer vuelo directamente, desde una posición que represente al observador que le importa.

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

El primer comando realiza un handshake y muestra los parámetros negociados, incluida la versión del protocolo y el nombre que solicitó. El segundo captura los primeros paquetes de una conexión real, y el tercero extrae el campo SNI de esa captura. Si el campo está relleno, el observador que usted emuló puede leerlo.

Capture por separado en el lado del cliente y en el camino cuando los dos no coincidan, porque una captura local puede mostrar un nombre que un middlebox reescribe o descarta después. Capture también desde un host que no termine TLS por sí mismo, ya que un proxy que termina ve texto claro por diseño y no demuestra nada sobre lo que ve la red.

Tratar una extensión ECH como una afirmación, no como una prueba

Ver una extensión ECH en un ClientHello no significa que la conexión usara ECH. Los clientes envían GREASE ECH cuando no tienen una configuración utilizable, justo para que sus handshakes parezcan uniformes. La extensión está presente, el hello interno es un señuelo, y el nombre real sigue siendo legible.

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

El primer comando muestra si el origen publica un registro de recursos HTTPS con un parámetro de configuración ECH, que es como los clientes aprenden la clave. El segundo busca información de estado del handshake, aunque el mensaje de éxito de un cliente es la prueba más sólida. La aceptación es lo que importa: un servidor que no tiene la clave correspondiente no puede descifrar el hello interno, y la conexión retrocede.

Compruebe también el cliente, ya que el soporte del navegador y la configuración varían según la versión y la plataforma. Una política basada en «los navegadores modernos usan ECH» es una suposición sobre un parque, no un hecho sobre su parque. Inventaríe las versiones que realmente se conectan y luego pruebe una de cada una. La misma página que funciona desde un navegador de escritorio actual puede no ocultar nada a un cliente más antiguo en la misma red.

Escribir el alcance del observador en la política

Indique dónde está el observador y qué es visible en ese punto antes de decidir en qué puede apoyarse un control. La conexión de un navegador a un sitio web, un transporte VPN externo y un proxy que termina TLS exponen cada uno un conjunto distinto de hechos, y una regla escrita para una posición rara vez se traslada limpiamente a otra.

Si un control depende de leer el SNI, pruebe cómo se comportan los clientes desplegados cuando ECH está disponible y cuando no. Luego registre la consecuencia de compatibilidad, porque un filtro que deja de coincidir en silencio es peor que uno que nunca se desplegó.

Por último, mantenga la incertidumbre en el registro. Sustituir una vieja afirmación universal por una más nueva deja el mismo hueco bajo otro nombre de protocolo, y el siguiente revisor le creerá con la misma firmeza.