Resumo

  • O 0-RTT do TLS 1.3 reduz a latência de uma conexão retomada, mas não impede de forma inerente o replay de dados enviados antes do handshake.
  • Um controle defensável liga a aceitação no transporte à semântica da requisição, à idempotência da aplicação, à autorização vigente e ao efeito efetivamente confirmado.

Imagine um serviço de pagamentos que permite a um cliente conhecido retomar uma sessão TLS e enviar uma transferência como early data, isto é, antes do fim do novo handshake. Um ponto de presença decifra e encaminha a requisição. Uma cópia reproduzida chega a outro ponto dentro da janela de aceitação do tíquete de sessão. Os dois registram early data válida; o sistema contábil recebe dois comandos. O transporte cumpriu o que prometeu. A aplicação presumiu uma garantia que nunca foi dada.

Economizar uma viagem não remove o limite de segurança

A RFC 8446 permite que um cliente retomando com chave pré-compartilhada envie dados de aplicação 0-RTT antes de concluir um novo handshake. Isso pode melhorar a resposta de leituras sensíveis à latência e de operações que toleram repetição.

O limite é explícito: o TLS não oferece proteção inerente contra replay para dados 0-RTT. Um invasor que registra o primeiro fluxo pode repetir o ClientHello e os dados associados. O servidor ainda pode autenticar o contexto de retomada e decifrar corretamente os bytes. A aceitação criptográfica prova que o conteúdo cabe em um contexto de early data aceito; não prova entrega única nem execução única.

Essa diferença some facilmente da telemetria. Um painel pode mostrar tíquete válido, 0-RTT aceito e resposta bem-sucedida. Nenhum desses campos informa se o mesmo comando atingiu outro processo, região ou caminho de nova tentativa. Um evento TLS verde é uma afirmação menor do que um resultado de negócio ocorrido exatamente uma vez.

Proteção contra replay é uma disciplina operacional, não uma caixa marcada

A RFC 8446 descreve tíquetes de sessão de uso único, registro de ClientHello e verificações de validade baseadas na idade do tíquete e no horário observado. Cada opção cria dependências. Tíquetes únicos precisam de estado de aceitação consistente. O registro exige uma base de detecção de replay disponível e limitada. A verificação temporal depende de relógios, tolerâncias e de uma escolha explícita sobre a janela de risco restante.

Em uma infraestrutura de borda distribuída, uma decisão local não vira prova global. Se dois pontos aceitam o mesmo material de retomada sem compartilhar a decisão de uso único, “não visto aqui” não significa “não visto em lugar algum”. Se o modo de contingência aceita enquanto o estado de proteção contra replay está indisponível, a política de disponibilidade ampliou a superfície de execução. Isso pode ser razoável, mas precisa ficar registrado.

Rejeitar early data também não elimina a responsabilidade da aplicação. O cliente pode reenviar depois do handshake. Se a primeira tentativa atravessou a fronteira da aplicação antes de a rejeição ficar visível, a nova tentativa pode duplicar o efeito. A evidência deve acompanhar aceitação, rejeição, encaminhamento, reenvio e confirmação final.

O HTTP expõe a decisão que faltava

A RFC 8470 define o uso de early data em HTTP e separa responsabilidades de cliente, intermediário e origem. O cliente não deve colocar casualmente uma operação insegura em early data. O intermediário precisa preservar o sinal de chegada antes do handshake. O servidor que não aceita o risco pode responder 425 Too Early, levando o cliente a tentar novamente fora do 0-RTT.

O código é uma transferência de controle, não uma declaração de que toda requisição aceita seja inofensiva. O nome do método também não basta. Uma leitura aparentemente segura pode causar cobrança, consumir uma alocação escassa ou registrar um evento de auditoria. Uma operação de gravação nominalmente idempotente deixa de sê-lo quando sua chave falta ou tem escopos diferentes entre regiões. Segurança contra replay pertence à operação conforme implementada sob o estado atual.

O QUIC torna a mesma fronteira operacional. A RFC 9001 incorpora early data do TLS ao QUIC; o servidor pode rejeitar 0-RTT e o cliente deve tratar o resultado. O caminho de reenvio faz parte do grafo de execução. Contar apenas pacotes QUIC aceitos não demonstra que o comando foi aplicado uma única vez.

Produza um registro auditável da decisão sobre early data

O objeto durável deve ligar a impressão digital e a idade do tíquete, a referência ao ClientHello ou handshake, o ponto de presença que aceitou, o mecanismo e a janela de proteção contra replay, a impressão digital da requisição, o método e a classe de efeito, a chave de idempotência, o principal e a versão da política de autorização, o encaminhamento, o histórico de tentativas, o efeito confirmado e os horários da decisão.

O recibo deve preservar incerteza. Unicidade local não prova unicidade em toda a frota. Tíquete válido não prova autoridade de negócio atual. Uma impressão não garante semântica equivalente se cabeçalhos ocultos, estado da conta ou escopo regional mudaram. Rejeição no transporte não prova que nenhum componente posterior viu a primeira tentativa.

Essa separação torna a escolha de desempenho governável. Equipes podem permitir 0-RTT para operações cuja repetição seja inofensiva, exigir idempotência global para operações de gravação delimitadas ou recusar early data quando autorização e efeitos irreversíveis não puderem ser decididos com segurança. A métrica útil não é a porcentagem de handshakes acelerados, mas a de operações antecipadas cujo histórico continua explicável.

Fontes