ECH ativado, mas SNI ainda visível: como verificar a criptografia do nome do site em 2026

```html

ECH — a criptografia do nome do site no handshake TLS — recebeu o status de padrão em março de 2026 (RFC 9849, Standards Track). Firefox e Chrome o ativam por padrão, e a Cloudflare distribui chaves para quase todos os seus clientes. No entanto, para a maioria dos usuários, o ECH não funciona silenciosamente: o navegador recorre ao handshake comum, e o provedor ainda vê para onde você está indo.

Abaixo, veja como verificar em um minuto se o SNI está realmente criptografado para você, por que ele geralmente não é criptografado e em quais cenários o ECH é fundamentalmente inútil (spoiler: para anti-detecção e parsing — quase sempre).

O que exatamente o ECH oculta — e o que não oculta

No TLS 1.3 comum, tudo é criptografado, exceto a primeira mensagem — ClientHello. Nela, o campo SNI com o domínio ao qual você está se conectando está em texto claro. É exatamente pelo SNI que a maioria dos sistemas de filtragem funciona: o IP é único para milhares de sites atrás de um CDN, enquanto o domínio é visível.

O ECH divide o ClientHello em duas partes:

• ClientHelloOuter — é enviado em aberto, mas com um domínio falso como envoltório. Para a Cloudflare, isso é cloudflare-ech.com.
• ClientHelloInner — o domínio real, ALPN e a lista de cifras, criptografados com a chave pública do servidor.

A chave para essa criptografia é obtida pelo navegador não da conexão, mas do DNS — do registro HTTPS (tipo 65), parâmetro ech=. Daqui vem a principal consequência, que muitos esquecem: o ECH é impossível sem DNS criptografado. Se a consulta DNS é feita em UDP/53 aberto, o observador simplesmente vê o nome do domínio antes do handshake, e o resolvedor filtrante pode cortar o parâmetro ech= da resposta — e o ECH não será ativado.

O que o ECH não oculta de forma alguma:

• O endereço IP de destino — sempre visível;
• o volume e os tempos do tráfego;
• o fingerprint TLS do cliente (JA3/JA4) — o conjunto de cifras e extensões permanece na parte aberta;
• você para o próprio site — o servidor, após a descriptografia, vê tudo o que via antes.

O último ponto é a razão pela qual o ECH não tem relação com a evasão de sistemas anti-bot. A Cloudflare, DataDome e Akamai operam do lado do servidor: não importa para eles se o SNI foi criptografado durante o caminho. Se a tarefa é não ser detectado durante a automação, um nível completamente diferente entra em ação: a falsificação do próprio fingerprint TLS, que discutimos no material sobre como contornar o fingerprint JA4 usando curl-cffi.

Verificação nº 1: o ECH está funcionando agora (10 segundos)

Abra no navegador:

https://crypto.cloudflare.com/cdn-cgi/trace

Encontre a linha sni=. Existem duas possibilidades:

• sni=encrypted — o ECH está funcionando, o nome do site está oculto no caminho;
• sni=plaintext — o ECH não foi aplicado, o domínio foi enviado em texto claro.

O mesmo endereço através de curl no terminal sempre retornará sni=plaintext — o curl comum não suporta ECH, e isso é um bom indicador: assim se parece o "desligado".

Verificação nº 2: o domínio tem uma chave ECH (dig, sem navegador)

O ECH será ativado apenas se o domínio tiver um registro DNS HTTPS com o parâmetro ech=. Veja o registro bruto:

dig +short TYPE65 example.com @1.1.1.1

No retorno, procure os bytes FE0D — este é o código de extensão do ECH, seguido pelo ECHConfig. Um exemplo prático: no momento da preparação deste material, tanto crypto.cloudflare.com quanto nosso domínio proxycove.com tinham um registro de 133–136 bytes que continha tanto FE0D quanto o nome falso cloudflare-ech.com em formato hexadecimal. No entanto, o próprio cloudflare.com tinha um registro curto, de 61 bytes: apenas ALPN e dicas de IP, sem ECH. Ou seja, mesmo dentro da infraestrutura da Cloudflare, o ECH não é distribuído para todos os domínios — não se surpreenda se um site específico não o tiver.

Se o dig retornar ignoring invalid type HTTPS — você está usando uma versão antiga da ferramenta, utilize a forma numérica TYPE65, como no comando acima.

Por que o ECH não está ativado para você: cinco razões em ordem

1. DNS criptografado está desativado. Sem DoH, o navegador não receberá o ECHConfig de forma confiável. No Firefox: Configurações → Privacidade → DNS sobre HTTPS no modo "Aumentada" ou "Máxima proteção". No Chrome: Configurações → Segurança → Usar DNS seguro.
2. O domínio simplesmente não tem um registro HTTPS com ech= — verificado com o comando do bloco acima. Aqui, nada depende de você; é uma decisão do proprietário do site e de seu CDN.
3. O resolvedor corta o parâmetro. Servidores DNS corporativos e de provedores costumam fornecer registros HTTPS sem ech=. Verifique, solicitando o registro diretamente a um resolvedor público (@1.1.1.1) e comparando com a resposta do sistema.
4. As flags do navegador foram redefinidas. No Firefox, as configurações network.dns.echconfig.enabled e network.dns.http3_echconfig.enabled em about:config — ambas devem estar como true.
5. Um gateway de inspeção está no meio. Sobre isso — a próxima seção.

Como o ECH é quebrado: dois esquemas diferentes

Firewall corporativo: redução silenciosa

Os fornecedores de equipamentos de rede lançaram receitas prontas contra o ECH — eles não estão dispostos a perder a visibilidade do tráfego. A Cisco, por exemplo, desde a base de aplicativos VDB 416 (outubro de 2025) define "Servidores ECH" como um aplicativo separado e oferece duas abordagens: interceptar a conexão recriando o certificado e cortar a extensão encrypted_client_hello do ClientHello, ou agir de forma mais simples — no nível DNS: bloquear registros HTTPS para domínios ECH, cortar DoH/DoT/DoQ, bloquear o domínio canário use-application-dns.net e permitir DNS apenas em servidores corporativos.

A astúcia do primeiro esquema é que ele não parece uma bloqueio. O servidor, ao não ver a extensão ECH, responde normalmente, o cliente considera o ECH "desligado com segurança" e se reconecta já com o SNI aberto. O site se abriu, não há erros — e o nome do domínio foi para o log do gateway.

Nível estatal: a conexão simplesmente morre

O exemplo russo é notável por sua precisão. Desde 5 de novembro de 2024, a filtragem só é ativada quando há coincidência de dois sinais ao mesmo tempo: SNI com o valor cloudflare-ech.com mais a presença da extensão ECH. Separadamente, nenhum dos dois provoca bloqueio — o ECH para outros domínios envoltórios (por exemplo, os de teste defo.ie ou tls-ech.dev) passa. Isso é implementado não com a reinicialização da conexão, mas com descartes silenciosos de pacotes: a página fica pendurada e cai por timeout. Tanto o HTTP/2 baseado em TCP quanto o QUIC/HTTP-3 são afetados. O Roskomnadzor então declarou diretamente que o uso do TLS ECH viola a legislação russa e recomendou que os proprietários de sites deixassem a CDN Cloudflare — milhares de recursos perfeitamente legais, incluídos na mesma envoltória, foram pegos de uma só vez.

No Firefox, nessa situação, cerca de um minuto depois, ele tenta novamente já sem ECH — ou seja, no final, entrega o SNI aberto, o que a especificação não recomenda fazer por razões de segurança. Se você observar "o site carrega exatamente por um minuto, depois se abre" — isso é quase certamente o que está acontecendo.

Quando o ECH não é suficiente e o que usar em vez dele

Vamos analisar as tarefas de forma honesta.

• Privacidade do provedor na internet doméstica. ECH + DoH — uma melhoria boa e gratuita. Funciona onde não é cortado.
• Contornar a filtragem. O ECH não foi projetado para isso, e a prática confirmou: assim que começou a interferir nos filtros, aprenderam a identificá-lo e silenciá-lo completamente. Não se pode contar com ele como uma ferramenta de acesso.
• Parsing, multi-contas, automação. O ECH não oferece nada: o site alvo vê seu IP, seu JA4 e seu histórico de solicitações. Apenas a origem do IP e a qualidade do fingerprint são relevantes.

Em todos os casos onde o ECH não funciona, um nível mais bruto, mas confiável, entra em ação: realizar o handshake TLS fora da rede observável. Quando o tráfego passa por um proxy, o observador em seu canal vê apenas a conexão com o nó proxy — nenhum SNI do site alvo está presente, independentemente de o domínio suportar ECH ou não. Para acesso diário e trabalho com serviços sensíveis à reputação do IP, proxies residenciais são adequados; para aplicativos móveis e plataformas que são especialmente exigentes quanto ao tipo de conexão, proxies móveis.

E não se esqueça do DNS: um proxy no navegador não garante que os nomes sejam resolvidos através dele. Um vazamento de DNS revela exatamente o que você tentou ocultar — como verificar isso, discutimos em uma instrução separada sobre como verificar proxies para vazamento de DNS. Se a questão é realmente uma análise profunda do tráfego no canal, você deve olhar não para o ECH, mas para o próprio transporte.

Lista de verificação rápida

1. Abrir crypto.cloudflare.com/cdn-cgi/trace e verificar a linha sni=.
2. Se plaintext — ativar DoH no navegador e verificar novamente.
3. Se não ajudou — verificar a presença da chave no domínio: dig +short TYPE65 domínio @1.1.1.1, procurar FE0D.
4. Se a chave existe, mas o ECH não é aplicado — comparar a resposta dos resolvedores públicos e do sistema: provavelmente, o parâmetro está sendo cortado durante o caminho.
5. A conexão fica pendurada por um minuto e se abre — o ECH está sendo silenciado no nível da rede; o ECH aqui não ajudará, é necessário outro transporte.

Conclusão

O ECH é uma última brecha cuidadosamente fechada na privacidade do TLS, e não um meio de acesso e muito menos uma ferramenta para automação. Ele depende do DNS criptografado, é desligado no meio sem um único erro na tela e é silenciado completamente onde começa a interferir. Vale a pena verificá-lo — os dois comandos acima levam um minuto. Mas construir sobre ele uma forma de contornar bloqueios ou proteção contra sistemas anti-bot é inútil: essas tarefas são resolvidas no nível de quem vê o IP e o fingerprint TLS do servidor do outro lado.