# Encrypted Client Hello e DoH: o que os firewalls de perímetro deixaram de ver

> O ECH (RFC 9849) esconde o nome de host real no handshake TLS, e o DoH esconde a consulta DNS. O que isso tira dos firewalls de rede, o que não tira, e para onde a visibilidade se desloca.

HisnLabs Security & Research Team · Published 2026-09-25
Canonical: https://hisnlabs.com/pt-br/blog/encrypted-client-hello-ech-doh-blind-perimeter-firewalls

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](https://www.rfc-editor.org/rfc/rfc8484.html)) já escondia a consulta DNS que precede uma conexão. O Encrypted Client Hello, agora publicado como [RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html), 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](https://www.rfc-editor.org/rfc/rfc9849.html); [explicação da Cloudflare](https://blog.cloudflare.com/encrypted-client-hello/)).

*O que um observador de rede vê (ilustrativo)*

```text
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](https://www.rfc-editor.org/rfc/rfc9460.html)), 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:

*Terminal, macOS 26.7, 25 de setembro de 2026*

```console
$ 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 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](https://chromestatus.com/feature/6196703843581952)), 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:

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

Entã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 |

*Em um front end compartilhado por vários provedores, o IP de destino costuma identificar o provedor, não o site.*

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.

> **Warning:** Afirmações de que o ECH torna o tráfego "impossível de rastrear" ou a filtragem de perímetro "obsoleta" exageram: IPs, tempos, volumes e o dispositivo continuam visíveis. O que se perde é o nome de host, e com ele a alavanca de política mais fácil de usar.

## 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 FireAI Pilot) 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](https://hisnlabs.com/fireai/pt-br/download).

## Sources

- [RFC 9849: TLS Encrypted Client Hello](https://www.rfc-editor.org/rfc/rfc9849.html)
- [RFC 9460: SVCB and HTTPS DNS resource records](https://www.rfc-editor.org/rfc/rfc9460.html)
- [RFC 8484: DNS Queries over HTTPS (DoH)](https://www.rfc-editor.org/rfc/rfc8484.html)
- [Cloudflare: Good-bye ESNI, hello ECH!](https://blog.cloudflare.com/encrypted-client-hello/)
- [Chrome Platform Status: Encrypted Client Hello](https://chromestatus.com/feature/6196703843581952)