Resumo

  • ClientHelloInner, envoltória externa e public_name do servidor voltado ao cliente são fatos distintos. O nome público não é o nome do backend privado.
  • Configuração DNS, aceitação de ECH, validação TLS e êxito da aplicação precisam de provas próprias; uma camada não conclui a outra.

A RFC 9849 separa os valores privados em ClientHelloInner e os valores inocentes, com a extensão ECH, em ClientHelloOuter. O cliente cifra o interior com uma chave pública ECH e o liga ao exterior por dados autenticados. Isso impede uma classe de alteração do envelope. Não declara que o registro DNS, o endereço público, o serviço de borda, o terminador TLS e o principal da aplicação pertencem ao mesmo ator.

O public_name tem uma função específica: é o nome DNS do servidor voltado ao cliente, confiável para atualizar a configuração ECH e ajudar a recuperar uma configuração antiga. Em geral ele aparece no SNI externo. É uma superfície pública de roteamento e recuperação, não o nome do origin privado, um certificado de propriedade ou uma confirmação de identidade para todos os domínios protegidos.

No modo compartilhado, frente e backend podem ser a mesma parte. No modo dividido, o servidor de frente retransmite ao backend que termina TLS e não obtém o texto claro da conexão. A especificação pressupõe um canal autenticado entre ambos e pressupõe que o atacante não correlacione os dois trechos; não define o mecanismo exato dessa prevenção. Ver ECH na rede não audita essas premissas.

Aceitar ECH também é um fato de escopo estreito. O servidor aceita e usa o interior, ou rejeita e usa o exterior. Após a rejeição, a conexão não serve para dados de aplicação do cliente ECH e pode oferecer configuração nova para repetição. Aceitação não prova validação local da cadeia, correspondência com a identidade esperada, autorização de aplicação ou conclusão de uma requisição.

RFC 8446 deixa TLS independente do protocolo de aplicação: a negociação cria parâmetros, autenticação quando usada e chaves, mas não define o sentido do negócio. Âncoras de confiança e validação detalhada permanecem separadas. A RFC 9460 permite que SVCB/HTTPS forneçam chaves e endpoints alternativos com capacidades ou operadores diferentes. Um registro DNS mostra uma instrução possível, não o endpoint final nem um serviço concluído.

O relatório operacional deve manter campos próprios para origem/TTL da ECHConfig, resolvedor e cache, aceitação, identidade esperada e validação, canal frente-backend, endpoint escolhido e resultado da aplicação. Um pacote pode preencher um campo; não deve preencher os demais por suposição.

Fontes