Resumo

  • O ECH cifra um ClientHelloInner com o SNI verdadeiro e o transporta dentro de um ClientHelloOuter público.
  • A proteção só se fecha quando DNS, cliente, servidor voltado ao cliente e backend concordam sobre configuração, chave, aceitação e tentativa.
  • Consulta DNS, endereço IP e outras pistas continuam fora desse envelope; publicar ech não prova que a conexão foi protegida.

A privacidade começa antes do primeiro pacote TLS

O server_name de RFC 6066 permite escolher um serviço entre vários que compartilham infraestrutura. Como RFC 8446 faz do ClientHello a primeira mensagem do TLS 1.3, o nome precisava aparecer cedo, antes que o restante do handshake estivesse protegido.

RFC 9849, padrão IETF publicado em março de 2026, cria dois cumprimentos. O interno leva o nome real e outros parâmetros sensíveis. O externo apresenta um nome público e contém a extensão com o bloco interno cifrado por HPKE a partir de um ECHConfig.

O servidor de frente aceita e abre o interior, ou rejeita a oferta e trabalha com o exterior. O cliente verifica qual resultado ocorreu. Quando ECH foi oferecido e rejeitado, a conexão não serve para dados de aplicação; ela informa uma nova tentativa com configuração atual, evitando que falha de privacidade pareça sucesso.

A porta compartilhada passa a guardar uma função precisa

No modo compartilhado, front-end e terminador TLS são o mesmo sistema. No modo separado, a porta abre o cumprimento interno e o entrega a um backend diferente, que termina TLS. Ela aprende o suficiente para rotear, mas não precisa terminar o fluxo protegido da aplicação.

O DNS publica a configuração. O cliente decide oferecê-la. O front-end mantém a chave privada e versões anteriores ainda presentes em cache. O backend confirma a aceitação vinculada à transcrição. Uma ativação isolada em qualquer um desses pontos não basta.

Rotação mostra o conflito operacional. Trocar rápido limita a exposição de uma chave comprometida; trocar antes que caches expirem aumenta rejeições. Manter muitas chaves amplia o custo de tentativas de abertura. O padrão estabelece procedimentos, mas deixa o intervalo para a realidade de cada serviço.

O DNS entrega a instrução

RFC 9848 define o parâmetro ech para SVCB e HTTPS de RFC 9460. Esses registros dizem ao cliente, antes da conexão, quais endpoints e parâmetros usar.

Por isso uma resposta omitida pode neutralizar a proteção. Misturar alternativas com e sem ECH permite que um intermediário bloqueie as protegidas e deixe a clara; o RFC não recomenda esse arranjo. Bloquear a consulta SVCB inteira pode impedir o cliente de descobrir que havia ECH.

DNS cifrado reduz a observação no acesso, mas o resolvedor ainda recebe o nome. O IP do front-end continua exposto. O ECH remove o SNI de um ponto específico; não apaga todas as pistas da rede.

O conjunto precisa parecer um conjunto

A meta depende de vários nomes compartilharem configuração e comportamento público. Uma chave distinta para cada origem pode produzir um conjunto de tamanho um. Uma preferência criptográfica exclusiva, ordem de extensões, tamanho de cookie ou padrão de nova tentativa também pode denunciar um membro.

O interior cifrado pode estar correto enquanto o exterior funciona como etiqueta. Avaliar ECH exige comparar origens no mesmo grupo, não apenas observar que uma delas decifrou.

GREASE torna o diagnóstico mais honesto

GREASE ECH envia uma forma plausível para testar se intermediários toleram a extensão e para dar cobertura ao uso real. Um front-end, portanto, não deve concluir que toda falha de abertura é defeito: o valor pode ser GREASE. Configurações de tentativa, ciclos entre nós e o alerta ech_required são evidências melhores.

O que permanece desconhecido

Os RFCs não medem adoção, navegadores, resolvedores nem redes específicas. Também não revelam o tamanho real do conjunto de um provedor. Essas perguntas exigem outra coleta; não podem ser preenchidas por suposição.

Fontes