Resumo

  • A conclusão do handshake QUIC é local e depende da perspectiva de cada endpoint.
  • HANDSHAKE_DONE, ou o ACK 1-RTT qualificado no cliente, confirma uma transição de protocolo e leva ao descarte das chaves Handshake.
  • A confirmação precisa ser combinada com evidências de 0-RTT e do resultado da aplicação antes de indicar prontidão.

O problema aparece quando um painel transforma uma informação estreita em uma promessa ampla. HANDSHAKE_DONE chega, o indicador fica verde e a equipe entende que o serviço está pronto. Mas o servidor pode ter rejeitado os dados antecipados. Nesse caso, o cliente precisa reiniciar todos os fluxos e o estado da aplicação associado a eles. O sinal é verdadeiro; o diagnóstico extraído dele é que pode estar errado.

A RFC 9001 define a conclusão do handshake a partir do endpoint local. A pilha TLS local precisa ter enviado uma mensagem Finished e verificado a mensagem Finished do par. Essa condição não ocorre necessariamente ao mesmo tempo nos dois lados. Logs e alertas devem conservar o ponto de vista observado, em vez de tratar uma transição local como um evento simultâneo da conexão inteira.

Os critérios de confirmação também mudam conforme o papel. No servidor, o handshake é confirmado quando termina, e o servidor deve enviar HANDSHAKE_DONE assim que isso acontecer. No cliente, receber HANDSHAKE_DONE confirma o handshake. O cliente também pode inferir a confirmação a partir de um ACK que cubra um pacote enviado com chaves 1-RTT. A RFC 9000 autoriza somente o servidor a enviar HANDSHAKE_DONE. O frame informa que o servidor recebeu e processou o pacote Handshake do cliente; não é uma resposta da aplicação.

O significado principal está no ciclo de vida das chaves. Quando há confirmação, o endpoint deve descartar as chaves Handshake. A época criptográfica Handshake deixa de ser usada. Isso não mostra que a negociação do protocolo de aplicação terminou, que a requisição chegou ao código da aplicação, que um armazenamento persistente funcionou ou que um serviço dependente está saudável.

As chaves Initial seguem outra regra. O cliente as descarta quando envia seu primeiro pacote Handshake. O servidor as descarta quando processa com sucesso seu primeiro pacote Handshake. A evidência é diferente, portanto o descarte de Initial não deve ser confundido com confirmação nem com descarte de Handshake. Um único evento no relatório pode apagar justamente a fronteira que a operação precisa entender.

A decisão sobre 0-RTT é separada. O servidor aceita 0-RTT quando inclui a extensão early_data em EncryptedExtensions e rejeita quando a omite. Depois da rejeição, o servidor não deve processar pacotes 0-RTT, e o cliente deve reiniciar todos os streams, inclusive o estado de aplicação ligado a eles. Um HANDSHAKE_DONE posterior não recupera nem valida o trabalho rejeitado.

A responsabilidade pela segurança contra replay é do protocolo de aplicação. Dados de aplicação enviados em 0-RTT podem ser processados várias vezes por causa de replay. O cliente não deve usar 0-RTT para dados de aplicação a menos que a aplicação solicite isso especificamente, e o protocolo deve definir os usos aceitáveis. A confirmação do handshake não prova segurança contra replay, execução exatamente uma vez, commit durável ou aceitação da requisição antecipada.

O ACK 1-RTT também não ganha um significado maior por estar ligado à confirmação. Quando cobre o menor número de pacote 1-RTT enviado pelo cliente, ele estabelece a condição definida pela RFC 9001. Não comprova consumo pela aplicação, gravação durável, autorização nem conclusão do negócio. É uma evidência de estado criptográfico, não uma confirmação de resultado empresarial.