TLS 1.3 segue enviando o nome do servidor en claro

Actualizar un listener a TLS 1.3 cambia o que un observador pode ler, pero non tanto como suxire o número de versión. O ClientHello segue a viaxar antes de que se negocie calquera cifrado, e nunha conexión ordinaria o nome de servidor solicitado está alí en texto claro. Encrypted Client Hello é o mecanismo que o oculta, e é un despregamento aparte cos seus propios requisitos previos. Execute estes catro pasos antes de escribir unha política que supoña calquera dos dous comportamentos.

Que expón realmente o handshake

TLS 1.3 cifra o certificado do servidor e a maior parte do handshake que segue o ServerHello. Todo o que o cliente envía primeiro queda fóra desa protección, porque as claves aínda non existen. A indicación do nome de servidor forma parte dese primeiro voo, e por iso un observador pasivo aínda pode lela sen romper nada.

A especificación ECH, RFC 9849, cambia isto ao cifrar un ClientHello interno para un servidor que coopera. O handshake externo permanece e leva un nome público que a rede pode ver, así que o despregamento segue necesitando unha identidade externa que teña sentido para os intermediarios. Ese nome externo é a parte que a xente pasa por alto cando espera que a conexión se volva anónima. É un nome de cobertura, non un nome oculto, e ten que resolverse e autenticarse coma calquera outro.

Nada disto oculta o camiño de entrega. Os enderezos de orixe e destino, os portos, os tamaños dos paquetes e os tempos seguen sendo observables, e a miúdo din máis sobre quen fala que o nome. A resolución de nomes e as relacións a nivel de aplicación son aínda outra capa, cada unha coa súa propia visibilidade.

Ler un ClientHello en lugar de supoñer

A versión no ServerHello non vos di que enviou o cliente. Mire o primeiro voo directamente, desde unha posición que represente o observador que vos 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

O primeiro comando realiza un handshake e mostra os parámetros negociados, incluída a versión do protocolo e o nome que solicitou. O segundo captura os primeiros paquetes dunha conexión real, e o terceiro extrae o campo SNI desa captura. Se o campo está cheo, o observador que emulou pode lelo.

Capture por separado no lado do cliente e no camiño cando os dous non coincidan, porque unha captura local pode mostrar un nome que un middlebox reescribe ou descarta despois. Capture tamén desde un equipo que non remate o TLS el mesmo, xa que un proxy que remata ve texto claro por deseño e non demostra nada sobre o que ve a rede.

Tratar unha extensión ECH como unha afirmación, non como unha proba

Ver unha extensión ECH nun ClientHello non significa que a conexión usase ECH. Os clientes envían GREASE ECH cando non teñen unha configuración utilizábel, xusto para que os seus handshakes parezan uniformes. A extensión está presente, o hello interno é un señuelo, e o nome real segue a ser lexíbel.

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'

O primeiro comando mostra se a orixe publica un rexistro de recurso HTTPS cun parámetro de configuración ECH, que é como os clientes aprenden a clave. O segundo busca información de estado do handshake, aínda que a mensaxe de éxito dun cliente é a proba máis sólida. A aceptación é o que importa: un servidor que non ten a clave correspondente non pode descifrar o hello interno, e a conexión retrocede.

Comprobe tamén o cliente, xa que o soporte dos navegadores e a configuración varían segundo a versión e a plataforma. Unha política baseada en «os navegadores modernos usan ECH» é unha conxectura sobre un parque, non un feito sobre o voso parque. Inventarie as versións que realmente se conectan e despois probe unha de cada. A mesma páxina que funciona desde un navegador de escritorio actual pode non ocultar nada a un cliente máis antigo na mesma rede.

Escribir o alcance do observador na política

Indique onde está o observador e que é visíbel nese punto antes de decidir en que se pode apoiar un control. A conexión dun navegador a un sitio web, un transporte VPN externo e un proxy que remata TLS expoñen cada un un conxunto distinto de feitos, e unha regra escrita para unha posición raramente se traslada limpa a outra.

Se un control depende de ler o SNI, probe como se comportan os clientes despregados cando ECH está dispoñíbel e cando non. Despois rexistre a consecuencia de compatibilidade, porque un filtro que deixa de coincidir en silencio é peor que un que nunca se despregou.

Por último, manteña a incerteza no rexistro. Substituír unha vella afirmación universal por unha máis nova deixa o mesmo oco baixo outro nome de protocolo, e o seguinte revisor crerá nela coa mesma firmeza.