Resumo

  • HelloRetryRequest não reinicia o TLS 1.3. O segundo ClientHello repete o primeiro, salvo uma lista restrita de mudanças autorizadas: nova parcela para o grupo pedido, remoção de early data, devolução de cookie e recálculo de binders.
  • O protocolo substitui os bytes de ClientHello1 por uma mensagem sintética message_hash com seu resumo e autentica esse compromisso junto com o pedido e as mensagens seguintes. Operar sem estado comprime a história; não a elimina.
  • A prova operacional precisa guardar os dois ClientHello, o motivo, a diferença permitida, a política de cookie, o grupo final, os alertas e a latência adicional. Um handshake concluído não demonstra que o pedido era válido nem que o grupo final era a preferência original do cliente.

A captura que começou tarde demais

O diagnóstico parecia simples. ClientHello2 levava uma única parcela, ServerHello selecionava o mesmo grupo e CertificateVerify e Finished passavam sem alerta. O painel resumiu: o cliente ofereceu esse grupo, o servidor o aceitou.

O primeiro pacote ausente contava outra história. O cliente havia listado vários grupos em supported_groups, mas antecipara uma parcela para outro grupo. O servidor não quis aquela previsão e enviou HelloRetryRequest para pedir um grupo já declarado compatível, porém ainda sem parcela no primeiro voo. A chave única do segundo Hello era resposta a uma decisão do servidor, não evidência da preferência inicial do cliente.

Configuração habilitada, compatibilidade anunciada, parcela prevista, grupo solicitado e seleção final são observações distintas. Quando a telemetria começa no segundo voo, ela atribui ao cliente a preferência do servidor, esconde uma volta de rede e compromete a análise de migração criptográfica.

Uma correção cercada por permissões explícitas

A especificação atual do TLS 1.3 exige que ClientHello2 seja igual a ClientHello1, exceto pelas mudanças expressamente permitidas. Se o pedido contém key_share, o cliente troca a lista por uma única parcela nova para o grupo indicado. Remove early_data, copia o cookie recebido e recalcula os binders PSK sobre o histórico que inclui a repetição. Uma extensão futura só pode permitir outra diferença se aparecer no pedido e definir a regra.

Não se trata de uma semelhança aproximada. É uma lista de autorização. O limite do que pode mudar é parte do contrato de segurança.

O grupo solicitado precisa constar do supported_groups original e não pode ser um grupo que já possuía parcela no primeiro key_share. Devem ser rejeitados um pedido sem mudança útil, um segundo pedido, uma suíte nunca oferecida ou um ServerHello cujo grupo contradiga o pedido.

Assim, retry deixa de ser uma licença aberta para tentar de novo. O servidor recebe autoridade para uma correção válida, uma única vez. Ele não pode reabrir todos os campos nem insistir até impor outra política.

message_hash mantém a primeira proposta na história

Os cálculos criptográficos do TLS dependem do resumo ordenado das mensagens do handshake. Um servidor que deseja emitir cookie e abandonar estado individual não quer armazenar cada ClientHello inteiro nem exportar um estado intermediário específico de biblioteca.

O TLS substitui ClientHello1 por uma mensagem sintética de tipo 254, message_hash, cujo corpo é Hash(ClientHello1). Depois entram HelloRetryRequest, ClientHello2, ServerHello e as mensagens de autenticação. CertificateVerify, Finished e o binder PSK posterior continuam comprometidos com a primeira proposta.

O resumo é um compromisso, não uma cópia reversível. Os pares podem detectar uma ruptura criptográfica, mas a equipe de operação não recupera extensões e parcelas originais somente a partir do hash. O protocolo prova continuidade; a captura ou registro estruturado explica o que mudou.

Dar suporte, antecipar e selecionar são estados diferentes

O cliente TLS 1.3 tenta economizar uma volta ao antecipar parcelas de chave na primeira mensagem. Gerar uma parcela para todo grupo compatível aumenta cálculo e tamanho. Enviar uma só reduz bytes, mas pode provocar HRR se o servidor exigir outro grupo também suportado.

Grupos híbridos pós-quânticos tornam a escolha mais visível. O OpenSSL expõe conjuntos de grupos, parcelas previstas e preferência do servidor. Sua documentação também observa que um ClientHello grande pode atravessar um limite de segmento TCP e encontrar firewall defeituoso; adiar uma parcela grande reserva a volta extra para servidores que realmente a exijam. O GnuTLS separa a política de grupos da opção de enviar uma única parcela TLS 1.3.

Uma linha de inventário dizendo “suporta X” é insuficiente. A implementação pode conhecer X, a configuração habilitá-lo, o primeiro Hello anunciá-lo sem parcela, o servidor pedi-lo e a conexão enfim selecioná-lo. Cada estado precisa de evidência própria.

Early data não sobrevive ao desvio

Se o primeiro ClientHello continha early_data, o segundo o remove. HelloRetryRequest demonstra que o caminho 0-RTT não foi aceito naquele handshake.

Mesmo assim, o cliente pode ter enviado bytes de aplicação antes de receber o pedido. Cabe à aplicação decidir se a operação pode ser repetida, se alguma resposta já foi observada e como reconciliar efeitos. O êxito posterior em 1-RTT não torna automaticamente idempotente uma ação com efeitos colaterais.

A telemetria deve separar tentativa de early data, rejeição por HRR, decisão de retransmitir e resultado de negócio. A marca “sessão retomada com sucesso” apaga a transição decisiva.

Um cookie só prova aquilo para que foi construído

O servidor pode inserir um cookie opaco em HelloRetryRequest e exigir sua devolução sem alteração. Ele pode comprometer o hash do primeiro Hello, parâmetros escolhidos, horário ou contexto de roteamento. Proteção de integridade prova origem e ausência de alteração dentro dos limites de custódia, validade e regras de verificação.

O DTLS 1.3 acrescenta outro uso: vincular o cookie ao endereço aparente para testar o caminho de retorno antes de amplificar uma resposta. Rotação de segredos, janelas sobrepostas e timestamps mostram que um token sem estado também tem ciclo de vida.

Alcançabilidade não é identidade. Devolver um cookie pode mostrar que alguém recebia tráfego naquele endereço durante um período; não identifica pessoa, função de dispositivo nem permissão de aplicação. Um cookie válido também não elimina a comparação entre os dois ClientHello.

Extensões entram na mesma história

Encrypted Client Hello oferece um exemplo limitado. O random de HelloRetryRequest é fixo, então ECH não pode colocar ali sua confirmação como faz no ServerHello. Em vez disso, define uma extensão encrypted_client_hello cuja confirmação deriva do ClientHello interno e do pedido modificado.

A lição não é transformar este estudo num guia ECH. Toda extensão precisa dizer o que pode mudar, onde aparece seu sinal e como ele entra no histórico autenticado. Ela não ganha uma negociação privada sem limites.

Evidência que continua útil depois do incidente

Um registro defensável começa antes do que muitos painéis chamam de conexão. Guarda hash e, quando permitido, campos analisados de ClientHello1; o HelloRetryRequest exato; hash do cookie, não seu segredo; campos de ClientHello2; e ServerHello final. Cada decisão se liga a versões de implementação e configuração.

Para grupos, registrar conjunto habilitado, ordem anunciada, parcelas previstas, preferência do servidor, grupo pedido, devolvido e negociado. Para o pedido, motivo, conformidade da diferença, alerta de rejeição e eventual segundo HRR. Para o efeito, RTT adicional, tamanho dos dois Hello, segmentação, resultado de early data, conclusão e população cliente.

Também é preciso conservar prova negativa. Testar rejeição de grupo não anunciado, grupo já compartilhado, pedido sem mudança, suíte alterada, segundo pedido e ServerHello incompatível. O executor do BoringSSL modela variantes inválidas porque rejeitar corretamente faz parte da interoperabilidade.

O handshake concluído é o fim do relato, não a prova de que todas as decisões anteriores eram legítimas. A prova está na sequência verificável de mudanças limitadas.

Fontes