Por vinte anos, firewalls de rede e proxies se apoiaram em um campo não criptografado para saber para onde ia o tráfego criptografado: a Server Name Indication (SNI), o nome de host que um cliente anuncia na primeira mensagem de um handshake TLS. O DNS over HTTPS (DoH, RFC 8484) já escondia a consulta DNS que precede uma conexão. O Encrypted Client Hello, agora publicado como RFC 9849, esconde a própria SNI. Juntos, os dois eliminam os dois sinais sobre os quais boa parte da filtragem de saída foi construída.
Como o ECH funciona: um ClientHello interno e um externo
Com o ECH, o cliente monta duas mensagens ClientHello. A interna carrega o destino real e os parâmetros sensíveis, e é criptografada com HPKE para uma chave pública que o servidor publicou com antecedência. A externa, enviada em texto claro, carrega um nome público compartilhado, tipicamente o nome do front end do provedor, de modo que um observador só descobre que o cliente está falando com aquele provedor (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 registro DNS HTTPS
O cliente precisa da chave pública ECH do servidor antes do handshake. Ele a obtém via DNS, no registro de recurso HTTPS (tipo 65, RFC 9460), cujo parâmetro ech carrega uma ECHConfigList. Consultamos um caso real. O dig que vem com o macOS não conhece esse registro pelo nome, então é preciso pedi-lo 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.comSe essa própria consulta DNS viajar por DoH, um observador de rede não vê nem a consulta nem, com o ECH, o nome de host no handshake. É exatamente essa combinação que este artigo aborda.
Se o ECH é usado depende do cliente
O ECH não é algo que uma rede ativa; cada cliente decide. Os navegadores já oferecem suporte a ele (Chrome Platform Status), geralmente atrelado ao uso de DNS criptografado. Muitos programas simplesmente não o utilizam. O endpoint de rastreamento da Cloudflare relata o que recebeu, e o curl embutido no macOS ainda envia o nome de host em texto claro:
curl -s https://crypto.cloudflare.com/cdn-cgi/trace | grep -E "^(tls|sni)="
tls=TLSv1.3
sni=plaintextEntão o quadro realista hoje é misto: os navegadores escondem cada vez mais o nome de host, muitos outros programas não escondem, e software escrito para escapar de monitoramento pode optar por usar ECH e DoH deliberadamente.
O que um firewall de perímetro perde, e o que mantém
| Sinal | TLS + DNS comuns | ECH + DoH |
|---|---|---|
| Consulta DNS (qual nome) | Visível na porta 53 | Escondida dentro de HTTPS até o resolvedor |
| SNI (qual nome de host) | Visível | Apenas o nome público compartilhado |
| IP e porta de destino | Visível | Ainda visível |
| Qual dispositivo na LAN | Visível | Ainda visível |
| Qual programa no dispositivo | Não visível | Não visível |
O resumo honesto é que a filtragem baseada em nome de host na borda deixa de funcionar para o tráfego com ECH, enquanto os controles baseados em IP continuam funcionando. Uma rede ainda pode recusar conexões a resolvedores DoH conhecidos, o que na prática também impede os navegadores de obter chaves ECH por DNS criptografado, e ainda pode bloquear faixas de endereços. O que ela não consegue mais fazer é distinguir dois sites atrás do mesmo provedor, nem permitir um e bloquear o outro, sem quebrar o TLS de formas que o próprio ECH foi projetado para detectar.
A visibilidade se desloca para o endpoint
O único lugar onde o nome de host nunca fica escondido é a própria máquina que faz a conexão: o programa o pediu pelo nome. É por isso que o ECH desloca o controle de saída em direção ao endpoint. Um firewall baseado em host nem precisa ler o handshake; ele vê qual processo abriu a conexão, para qual endereço e, quando o programa resolveu um nome, qual nome, tudo antes de qualquer byte criptografado sair da máquina. Ele também vê a única coisa que um dispositivo de rede nunca conseguiu ver, mesmo antes do ECH: qual aplicativo na máquina está se comunicando.
- Decida por aplicativo, não por nome de host: um navegador, um cliente de sincronização e um binário desconhecido recebem regras diferentes.
- Trate um programa que inicia seu próprio DoH para um resolvedor que o sistema não configurou como um sinal que merece atenção.
- Mantenha listas de bloqueio baseadas em IP na borda; elas continuam funcionando, e não custam nada.
Onde FireAI e HisnLabs entram nessa história
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: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso Autopilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.
Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em FireAI, da HisnLabs.