Resumo

  • ECH transforma o registro HTTPS/SVCB em configuração criptográfica ativa: a chave anunciada precisa corresponder à chave privada do edge efetivamente alcançado.
  • A medida relevante é a janela entre a primeira publicação DNS e a prontidão completa da frota, observada por aceitação, rejeição, retry, desativação segura e falha.
  • Configurações de retry consertam descompassos limitados; não tornam a publicação atômica nem absolvem ciclos persistentes.
  • Plataformas integradas diluem custódia, sobreposição e telemetria. Operações multi-CDN precisam de recibos portáveis de versão, ativação e rollback.

O DNS agora distribui estado de conexão

RFC 9849 separa o ClientHelloInner privado do ClientHelloOuter visível. O inner carrega o nome real e preferências sensíveis; o outer transporta a cápsula cifrada. O servidor de frente só a abre com a chave privada correspondente à ECHConfig recebida pelo cliente.

RFC 9848 define o parâmetro ech nos service bindings, e RFC 9460 organiza endpoint e parâmetros em registros SVCB/HTTPS. O DNS deixa de ser apenas endereço: passa a influenciar como a primeira mensagem TLS é montada.

Ativar a chave antes de publicar custa um período de sobreposição. Publicar antes de ativar cria uma janela em que o cliente encontra um edge incapaz de decifrar. Certificado e HTTPS comum podem continuar verdes; nenhum deles comprova aceitação ECH na primeira tentativa.

Quatro planos precisam concordar

O navegador decide se oferece ECH. A política do Chrome Enterprise diz que uso real depende também de suporte do servidor, registro HTTPS e rollout. A FAQ do Firefox registra ativação padrão desde o Firefox 119 e caminhos de desativação por empresa, controle parental ou middlebox confiável.

O resolver decide o que o navegador aprende. RFC 9460 admite que suprimir SVCB nega o benefício. A documentação da Cloudflare descreve supressão de respostas HTTPS e domínio canário como controles locais e alerta que reescrever o registro pode colidir com DNSSEC.

O DNS autoritativo escolhe versão, TTL e aliases. O edge escolhe quais grupos carregam a chave. Um recibo útil reúne hash de ECHConfigList, config_id, primeira observação DNS, TTL, prontidão por grupo, aceitação, retry e cauda de cache antigo.

Retry é telemetria operacional

ECH permite que o servidor envie uma configuração de retry para corrigir uma chave antiga. O mecanismo é necessário, mas sua leitura deve ser honesta: a segunda conexão bem-sucedida prova que a primeira encontrou um descompasso e pagou mais uma conexão para resolvê-lo.

RFC 9849 recomenda não aceitar outra configuração de retry quando a conexão já foi iniciada a partir de uma. Configurações múltiplas e inconsistentes aparecem como causa plausível. Uma correção que sempre anuncia outra versão não é tolerância a falhas; é ausência de inventário autoritativo.

Retry deve ser separado por versão, resolver, cliente e edge. Uma cauda breve de rotação pode ser controlada. Persistência em um local é incidente. A média global costuma transformar um grupo inteiro de servidores em arredondamento.

A privacidade inclui comportamento externo

ECH protege SNI, mas o conjunto de anonimato exige serviços externamente parecidos. Cookies de HelloRetryRequest, nomes de chave, ordem de extensões e erros diferentes poderiam distinguir backends. As normas registram esse mecanismo condicional de risco; este pacote não mede redução do conjunto de anonimato em uma implantação nomeada.

RFC 9849 trata o risco em split mode. RFC 9934 padroniza um arquivo PEM com chave privada e ECHConfigList correspondente. O formato ajuda portabilidade, não distribuição. Um arquivo correto no controlador não prova ativação no edge.

RFC 9180 define HPKE. A criptografia pode proteger perfeitamente uma cápsula destinada à chave que o último edge ainda não recebeu. O problema fica fora do cipher e dentro da mudança.

O prêmio da integração

Quem opera DNS e edge pode preparar a chave, confirmar a frota, publicar, manter sobreposição, observar retry e retirar a versão anterior numa fronteira. A Cloudflare documenta ECH padrão em zonas Free e configurável em outros planos. Não é taxa universal de sucesso; é evidência de que coordenação pode chegar como atributo de plataforma.

Num domínio multi-CDN, configuração comum, vários service bindings ou capacidades diferentes por rota exigem acordo. Custódia, TTL, cache, rollback e prova de prontidão viram cláusulas de fornecedor. A norma define mensagens, não sincroniza calendários.

O lock-in começa quando apenas o grafo interno do provedor demonstra qual versão estava ativa. Migrar requer chaves e reconstrução da confiança. Hashes, horários, grupos, aceitação e rollback exportáveis preservam a saída.

A conclusão sobre coordenação e lock-in é uma inferência analítica das superfícies divididas, não uma condição de mercado observada. O dono do domínio paga planejamento de sobreposição e portabilidade; o provedor DNS, publicação, TTL e evidência de cache; o operador edge, distribuição de segredo, telemetria e rollback; a empresa, testes de política do resolver e suporte; e o usuário, primeiras tentativas falhas e latência de retry. O contrato pode redistribuir dinheiro e trabalho, mas não apagá-los.

Um padrão falsificável

Cada rotação deve registrar hash, observações DNS, TTL, frota pretendida, ativação, aceitação inicial, retry, latência, desativação, falha e rollback.

A tese enfraquece se rotações repetidas mostrarem publicação só após 99,999% dos edges prontos, divergência abaixo de 0,01%, retry p99 abaixo de 25 ms, desaparecimento em TTL mais 30 segundos e troca multi-provedor equivalente sem orquestração proprietária comum. Fortalece se mais de 1% das primeiras tentativas exigirem retry, um grupo ficar divergente por mais de dois TTLs ou rollback ultrapassar 300 segundos.

São limites prospectivos, não estatísticas observadas. A precisão serve para rejeitar a tese, não para decorar desconhecimento.