Encrypted Client Hello e DoH: O Que as Firewalls de Perímetro Já Não Conseguem Ver

Durante vinte anos, as firewalls e os proxies de rede apoiaram-se num campo não cifrado para saber para onde ia o tráfego cifrado: o Server Name Indication (SNI), o nome de anfitrião que um cliente anuncia na primeira mensagem de um handshake TLS. O DNS sobre HTTPS (DoH, RFC 8484) já escondia a consulta DNS que precede uma ligação. O Encrypted Client Hello, agora publicado como RFC 9849, esconde o próprio SNI. Juntos, removem os dois sinais em que assentava a maior parte da filtragem de saída (egress).

Como funciona o ECH: um ClientHello interior e um exterior

Com o ECH, o cliente constrói duas mensagens ClientHello. A interior transporta o destino real e os parâmetros sensíveis, e é cifrada com HPKE para uma chave pública que o servidor publicou antecipadamente. A exterior, enviada em claro, transporta um nome público partilhado, tipicamente o nome do front-end do fornecedor, de modo a que um observador só saiba que o cliente está a falar com esse fornecedor (RFC 9849; explicação da Cloudflare).

TLS ClientHello (outer, cleartext)
  server_name:            cloudflare-ech.com      <- shared public name
  encrypted_client_hello: <HPKE ciphertext>        <- real hostname is inside

De onde vem a chave: o registo DNS HTTPS

O cliente precisa da chave pública ECH do servidor antes do handshake. Obtém-na do DNS, no registo de recursos HTTPS (tipo 65, RFC 9460), cujo parâmetro ech transporta uma ECHConfigList. Consultámos um registo real. O dig que vem com o macOS não conhece o registo pelo nome, por isso peça-o pelo número:

$ dig crypto.cloudflare.com TYPE65 +short
\# 133 0001000001000302683200040008A29F874FA29F884F000500470045 FE0D0041AF…
     …0012636C6F7564666C6172652D6563682E636F6D
# 0005 = the "ech" key, FE0D = ECH config version, and the last bytes decode to
# the ASCII public name: cloudflare-ech.com

Se essa própria consulta DNS viajar sobre DoH, um observador de rede não vê nem a consulta nem, com o ECH, o nome de anfitrião no handshake. É sobre essa combinação que trata este artigo.

Se o ECH é usado depende do cliente

O ECH não é algo que uma rede liga; cada cliente decide. Os navegadores foram lançando suporte (Chrome Platform Status), geralmente associado ao uso de DNS cifrado. Muito software não o usa de todo. O ponto de diagnóstico da Cloudflare reporta o que recebeu, e o curl incluído no macOS continua a enviar o nome de anfitrião em claro:

$ curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintext

Portanto, o panorama realista hoje é uma mistura: os navegadores escondem cada vez mais o nome de anfitrião, muitos outros programas não o fazem, e software escrito para escapar à monitorização pode optar por usar deliberadamente o ECH e o DoH.

O que uma firewall de perímetro perde, e o que mantém

O resumo honesto é que a filtragem baseada em nome de anfitrião na periferia deixa de funcionar para o tráfego ECH, enquanto os controlos baseados em IP não deixam. Uma rede continua a poder recusar ligações a resolvedores DoH conhecidos, o que na prática também impede os navegadores de obterem chaves ECH através de DNS cifrado, e continua a poder bloquear intervalos de endereços. O que já não consegue fazer é distinguir dois sítios por trás do mesmo fornecedor, ou permitir um e bloquear o outro, sem quebrar o TLS de formas que o ECH foi concebido para detetar.

A visibilidade desloca-se para o dispositivo final

O único sítio onde o nome de anfitrião nunca fica escondido é a máquina que faz a ligação: o programa pediu-o pelo nome. É por isso que o ECH desloca o controlo de saída para o dispositivo final. Uma firewall baseada no anfitrião não precisa sequer de ler o handshake; vê qual o processo que abriu a ligação, para que endereço e, quando o programa resolveu um nome, qual foi esse nome, antes de qualquer byte cifrado sair. Vê também a única coisa que um dispositivo de rede nunca conseguiu, mesmo antes do ECH: qual a aplicação na máquina que está a falar.

• Decida por aplicação, não por nome de anfitrião: um navegador, um cliente de sincronização e um binário desconhecido recebem regras diferentes.
• Trate um programa que inicia o seu próprio DoH para um resolvedor que o sistema não configurou como um sinal que merece atenção.
• Mantenha as listas de bloqueio baseadas em IP na periferia; continuam a funcionar, e não custam nada.

O papel do FireAI e da HisnLabs

ECH hides the hostname from the network, not from the machine making the connection: an on-device firewall such as FireAI still sees which process is connecting and where, and asks before an app it does not know goes online.

O FireAI é o produto da HisnLabs: uma firewall com IA que corre diretamente no seu Mac. Mostra, em linguagem clara, cada ligação que as suas aplicações fazem e deixa-o decidir o que sai do seu Mac — a IA funciona localmente, pelo que o seu tráfego nunca é enviado para nós nem para mais ninguém. A equipa de investigação em segurança da HisnLabs é quem mantém essas decisões fiáveis: cataloga que domínios são simples telemetria e quais são um serviço real, acompanha o país e a rede por detrás de uma ligação e treina o modelo local (a funcionalidade Autopilot) com padrões de tráfego reais, sem que nada disso saia do seu Mac.

Pode ler as decisões técnicas por detrás dele, ou experimentar o FireAI durante 17 dias, em FireAI, da HisnLabs.