Resumo

  • O TLS 1.3 permite que um cliente com material de retomada envie dados de aplicação junto com o ClientHello, economizando uma ou duas viagens de rede. Os dados são cifrados, mas não têm garantia de não repetição entre conexões.
  • O RFC 8470 colocou a decisão no recurso: intermediários carregam Early-Data: 1, a origem decide se tolera repetição e 425 recusa apenas o pedido cujo efeito não deve começar nesse contexto.
  • Ao receber 425, o agente pode tentar automaticamente de novo, mas a nova transmissão não pode usar early data. Método, alvo e corpo podem permanecer; o que muda é o tempo criptográfico. O HTTP/3 preservou o contrato sobre QUIC.

A viagem poupada tinha um preço

O handshake tradicional obriga o HTTP a esperar. Cliente e servidor trocam dados frescos, derivam chaves para aquela conexão e só então começam o trabalho de aplicação. Em enlaces longos, a ordem cobra latência.

Com uma chave pré-compartilhada e um ticket de uma sessão anterior, o TLS 1.3 permite ao cliente mandar aplicação junto ao ClientHello. O pedido 0-RTT sai sem ouvir o novo ServerHello e evita uma ou duas idas e voltas.

O RFC 8446 não esconde a troca. Early data é cifrado, porém não possui sigilo futuro e não recebe garantia de não replay entre conexões. Como saiu antes da nova aleatoriedade do servidor, não pode depender dela para se ligar à nova sessão.

Não é ausência de autenticação. O invasor não altera os bytes à vontade, não os converte em 1-RTT e não duplica o registro dentro da mesma conexão. A exposição é apresentar o voo inteiro em outra conexão que ainda reconheça o estado de retomada.

Um replay pode convocar um retry

Retry é uma decisão visível do cliente diante de falha ou resposta perdida. Replay pode ser iniciado por terceiro sem o cliente saber. São mecanismos diferentes, mas regiões inconsistentes podem combiná-los.

Uma região aceita a cópia e produz efeito. Outra rejeita o 0-RTT, conclui o handshake e deixa o cliente reenviar. Se a primeira resposta for ocultada, uma única intenção chega duas vezes: uma por reprodução, outra pela recuperação normal.

Tickets de uso único, gravação de ClientHello, janelas curtas e uma zona responsável por cada ticket reduzem o problema direto. Exigem estado compartilhado e comportamento prudente após reinício. Mesmo assim, o TLS não sabe se os bytes leem um arquivo inerte ou gastam um direito único.

A origem sabia mais do que o verbo

Métodos seguros e idempotentes oferecem uma primeira pista. Não oferecem uma auditoria do recurso. Um GET pode consumir URL assinada, iniciar computação cobrada, alterar cache ou registrar efeito relevante. Um POST com identificador transacional pode detectar repetição.

O RFC 8470 torna a tolerância ao replay específica do recurso. O cliente escolhe o que tenta cedo; o TLS conhece a fase; o gateway conhece o caminho; a origem conhece a consequência. Por isso a biblioteca TLS não pode habilitar nem reenviar 0-RTT sozinha: a aplicação precisa de perfil explícito.

Três formas de manter o efeito do lado de cá

O servidor pode rejeitar todo early data no TLS. A proteção é ampla, mas também perde a vantagem para todos os pedidos do voo, porque o TLS não escolhe uma mensagem HTTP individual.

Pode aceitar a chegada e adiar o processamento. Lê o suficiente para classificar e rotear, mas espera o handshake antes de escrever ou chamar sistemas externos. Pedidos multiplexados podem ter políticas diferentes.

Ou responde 425 Too Early a um pedido. A origem conserva o caminho rápido para recursos aprovados e devolve apenas a operação sensível ao cliente. A otimização vira permissão estreita, não padrão soberano.

A história precisou atravessar o CDN

Frequentemente, quem entende a ação não termina o TLS do usuário. Entre os dois há CDN, proxy e gateway. A conexão imediata da origem pode ser 1-RTT, embora o primeiro salto tenha recebido o pedido cedo.

Early-Data tem um único valor válido: 1. O intermediário que encaminha antes de completar o handshake com seu cliente deve adicionar a marca; quem a recebe não pode removê-la. A possibilidade de envio por outra instância também mantém a marca.

Esse bit é proveniência, não pedido de desempenho. Esperar no salto seguinte não apaga a cópia possível do salto anterior. Uma origem incapaz de processar a solicitação marcada deve retornar 425 mesmo sobre conexão já estabelecida.

Valores múltiplos ou inválidos são reduzidos ao mesmo risco conservador. O campo não aparece em respostas, trailers ou como opção Connection. Sua função é preservar uma incerteza, não fabricar confiança.

O reenvio muda o contexto, não o sentido

O agente que usou early data e recebeu 425 deve tentar de novo automaticamente. A condição decisiva é que a tentativa nova não seja early data. Ele espera o handshake e transmite como aplicação comum.

URI, método, corpo e ação podem continuar idênticos. Não é redirect. Também não é 421: a conexão pode ter autoridade para a origem. Não é 429 de cota, 503 de indisponibilidade ou 100 Continue de coordenação do corpo.

O servidor não deve usar 425 sem evidência de early data ou Early-Data: 1, pois um cliente comum pode não entender a recuperação. A resposta não é armazenável por padrão e não representa o recurso. O registro da IANA fixa o nome estreito Too Early.

Um intermediário só limpa o começo que conhece

Se o pedido chegou marcado, o intermediário encaminha o 425. A exposição começou antes dele e não desaparece com nova conexão para baixo.

Se o próprio intermediário foi o primeiro a receber o pedido como early data, sem marca anterior, pode esperar o handshake do cliente e repetir para a origem. Nesse caso ele conhece o começo da história e realmente move o pedido para fora dela.

Gateway não deve adiantar um pedido para origem que não compreenda RFC 8470. Quando não sabe, espera ou retorna 425. A borda não pode aceitar risco de aplicação em nome de quem suportará a perda.

A hora de agir vence a hora de chegar

Cabeçalhos podem chegar cedo e o corpo depois. No QUIC, um stream classificado como 0-RTT pode ser entregue após o handshake. A última chegada não altera a procedência.

O teste correto é quando começa o efeito. Analisar e escolher rota pode ser neutro; gravar, consumir token, disparar pagamento ou enfileirar não é. Todas as instâncias capazes de aceitar o mesmo ticket precisam compartilhar o invariante de não agir cedo, mesmo escolhendo mitigações diferentes.

Uma instância reiniciada não conhece os replays vistos antes. Enquanto a janela de registro cruza esse período cego, ela deve rejeitar 0-RTT. Esquecimento local não aumenta autoridade do pedido.

O HTTP/3 preservou duas provas diferentes

O RFC 9114 aplica RFC 8470 ao 0-RTT do QUIC. O cliente também envia antes de receber SETTINGS atuais e depende dos valores lembrados da sessão anterior.

O servidor rejeita 0-RTT quando não prova compatibilidade. Se aceitar, não pode depois anunciar limites menores que invalidem dados já enviados. Isso é separado da tolerância do recurso: SETTINGS protege estado do protocolo; 425 protege efeitos.

Fontes e limites da evidência

O conjunto fechado é TLS 1.3, RFC 8446, Using Early Data in HTTP, RFC 8470, HTTP/3, RFC 9114 e o registro IANA de status HTTP. Eles estabelecem regras e limites, não adoção atual, suporte universal, incidente nomeado, ganho medido ou execução exatamente uma vez.