Atualizar um listener para TLS 1.3 muda o que um observador pode ler, mas não tanto quanto o número da versão sugere. O ClientHello ainda viaja antes de qualquer encriptação ser negociada, e numa ligação comum o nome do servidor pedido fica ali em texto simples. Encrypted Client Hello é o mecanismo que o esconde, e é uma implantação separada com os seus próprios pré-requisitos. Execute estes quatro passos antes de escrever uma política que assuma qualquer dos dois comportamentos.

O que o handshake expõe realmente

O TLS 1.3 encripta o certificado do servidor e a maior parte do handshake que segue o ServerHello. Tudo o que o cliente envia primeiro fica fora dessa proteção, porque as chaves ainda não existem. A indicação do nome do servidor faz parte desse primeiro voo, e é por isso que um observador passivo ainda a pode ler sem quebrar nada.

A especificação ECH, RFC 9849, muda isto ao encriptar um ClientHello interno para um servidor cooperante. O handshake externo permanece e transporta um nome público que a rede pode ver, pelo que a implantação continua a precisar de uma identidade externa que faça sentido para os intermediários. Esse nome externo é a parte que as pessoas perdem quando esperam que a ligação se torne anónima. É um nome de cobertura, não um nome oculto, e tem de resolver e autenticar como qualquer outro.

Nada disto esconde o caminho de entrega. Os endereços de origem e destino, as portas, os tamanhos dos pacotes e os tempos continuam observáveis, e dizem frequentemente mais sobre quem fala do que o nome. A resolução de nomes e as relações ao nível da aplicação são ainda outra camada, cada uma com a sua própria visibilidade.

Ler um ClientHello em vez de assumir

A versão no ServerHello não lhe diz o que o cliente enviou. Olhe para o primeiro voo diretamente, a partir de uma posição que represente o observador que lhe interessa.

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 um handshake e mostra os parâmetros negociados, incluindo a versão do protocolo e o nome que pediu. O segundo captura os primeiros pacotes de uma ligação real, e o terceiro extrai o campo SNI dessa captura. Se o campo estiver preenchido, o observador que emulou pode lê-lo.

Capture separadamente no lado do cliente e no caminho quando os dois não concordam, porque uma captura local pode mostrar um nome que um middlebox mais tarde reescreve ou descarta. Capture também a partir de um anfitrião que não termina o TLS ele próprio, visto que um proxy que termina vê texto simples por conceção e não prova nada sobre o que a rede vê.

Tratar uma extensão ECH como uma afirmação, não como prova

Ver uma extensão ECH num ClientHello não significa que a ligação tenha usado ECH. Os clientes enviam GREASE ECH quando não têm uma configuração utilizável, precisamente para que os seus handshakes pareçam uniformes. A extensão está presente, o hello interno é um engodo, e o nome real continua legível.

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 origem publica um registo de recurso HTTPS com um parâmetro de configuração ECH, que é como os clientes aprendem a chave. O segundo procura informações de estado do handshake, embora a mensagem de sucesso de um cliente seja a prova mais forte. A aceitação é o que importa: um servidor que não detém a chave correspondente não pode decifrar o hello interno, e a ligação recua.

Verifique também o cliente, pois o suporte dos navegadores e a configuração variam com a versão e a plataforma. Uma política baseada em «os navegadores modernos usam ECH» é um palpite sobre um parque, não um facto sobre o seu parque. Inventarie as versões que realmente se ligam e depois teste uma de cada. A mesma página que funciona a partir de um navegador de secretária atual pode não esconder nada de um cliente mais antigo na mesma rede.

Escrever o âmbito do observador na política

Declare onde está o observador e o que é visível nesse ponto antes de decidir em que um controlo se pode apoiar. A ligação de um navegador a um sítio, um transporte VPN externo e um proxy que termina TLS expõem cada um um conjunto diferente de factos, e uma regra escrita para uma posição raramente se transfere de forma limpa para outra.

Se um controlo depende da leitura do SNI, teste como se comportam os clientes implantados quando o ECH está disponível e quando não está. Depois registe a consequência de compatibilidade, porque um filtro que deixa silenciosamente de corresponder é pior do que um que nunca foi implantado.

Por fim, mantenha a incerteza no registo. Substituir uma antiga afirmação universal por uma mais recente deixa a mesma lacuna sob outro nome de protocolo, e o próximo revisor acreditará nela com a mesma firmeza.

Artigos relacionados