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

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

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

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](https://www.rfc-editor.org/rfc/rfc8484.html)) já escondia a consulta DNS que precede uma ligação. O Encrypted Client Hello, agora publicado como [RFC 9849](https://www.rfc-editor.org/rfc/rfc9849.html), 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](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 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](https://www.rfc-editor.org/rfc/rfc9460.html)), 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:

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

```console
$ 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

| Sinal | TLS + DNS simples | ECH + DoH |
| --- | --- | --- |
| Consulta DNS (que nome) | Visível na porta 53 | Oculta dentro de HTTPS até ao resolvedor |
| SNI (que nome de anfitrião) | Visível | Apenas o nome público partilhado |
| IP e porta de destino | Visível | Continua visível |
| Que dispositivo na LAN | Visível | Continua visível |
| Que programa no dispositivo | Não visível | Não visível |

*Num front-end de fornecedor partilhado, o IP de destino identifica muitas vezes o fornecedor, não o sítio.*

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.

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

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