TLS 1.3: 0-RTT, Dados Antecipados e Retomada de Sessão

O TLS 1.3 (RFC 8446, 2018) reformulou o estabelecimento de conexão do TLS para reduzir a latência e remover complexidades legadas desnecessárias. Um estabelecimento completo do TLS 1.3 é concluído em 1-RTT: o cliente envia o ClientHello com os key_shares compatíveis (chaves públicas efêmeras ECDH) no primeiro envio; o servidor responde com o ServerHello, seu key_share, as EncryptedExtensions, o certificado e a mensagem de conclusão — tudo em uma única resposta. O cliente envia sua mensagem de conclusão e pode enviar imediatamente dados da aplicação. Em comparação com o estabelecimento de conexão de 2-RTT do TLS 1.2, isso reduz pela metade o tempo de configuração da conexão para novas sessões.

O TLS 1.3 usa HKDF (função de derivação de chaves baseada em HMAC) com uma sequência estruturada de derivação de chaves. Após a troca de chaves ECDHE, o segredo compartilhado alimenta uma hierarquia: Extract(early_secret, DHE) -> handshake_secret; depois, Extract(handshake_secret, 0) -> master_secret. A partir desses valores, HKDF-Expand-Label deriva chaves separadas para o tráfego de estabelecimento de conexão do cliente e do servidor, o tráfego da aplicação e a retomada. Essa separação clara garante que o comprometimento de uma camada de chaves não afete as outras — uma melhoria significativa em relação à derivação de chaves mais ad hoc baseada em PRF do TLS 1.2.

A retomada de sessão do TLS 1.3 usa chaves pré-compartilhadas (PSK) derivadas de sessões anteriores. Após um estabelecimento de conexão concluído, o servidor envia uma mensagem NewSessionTicket contendo uma identidade PSK e um valor de tíquete (um bloco criptografado que contém o segredo de retomada). Ao se reconectar, o cliente inclui a identidade PSK no ClientHello. Se o servidor a reconhecer, ambos os lados derivam uma nova chave de sessão a partir da PSK e de uma ECDHE nova, obtendo uma retomada em 1-RTT com sigilo de encaminhamento. O tíquete tem um período de validade configurável (normalmente 24 horas) e deve ser criptografado com uma chave rotativa no servidor.

O TLS 1.3 permite dados iniciais de 0-RTT para sessões retomadas. O cliente usa a PSK de uma sessão anterior para criptografar dados da aplicação enviados no primeiro envio — antes de qualquer confirmação do servidor. Isso elimina uma ida e volta para conexões com servidores visitados anteriormente, proporcionando latência quase nula em conexões repetidas. O servidor anuncia o suporte a 0-RTT no NewSessionTicket por meio da extensão early_data, com um max_early_data_size. O servidor precisa ter um mecanismo para aceitar ou rejeitar dados de 0-RTT e sinaliza a aceitação em EncryptedExtensions.

Os dados de 0-RTT têm uma limitação fundamental de segurança: são vulneráveis a ataques de repetição. Um atacante no caminho que capture o primeiro envio pode repeti-lo para o servidor, fazendo com que o servidor processe os dados iniciais novamente. Isso é inerente ao mecanismo — o servidor ainda não enviou nenhuma mensagem, portanto não há uma novidade fornecida pelo servidor. Mitigações: (1) Tíquetes de uso único (o servidor invalida um tíquete após o primeiro uso, utilizando um cache distribuído como memcached/Redis). (2) Tíquetes limitados por tempo (rejeitar 0-RTT após uma janela curta, por exemplo, 5 segundos). (3) Idempotência no nível da aplicação (permitir 0-RTT somente para operações seguras equivalentes a GET).

O mecanismo mais robusto de proteção contra repetição em 0-RTT é o uso de tíquetes de sessão de uso único. O servidor mantém um armazenamento de tíquetes usados (um cache distribuído em implantações com vários servidores). Quando chegam dados de 0-RTT, o servidor verifica se o tíquete já foi visto antes — se sim, rejeita os dados iniciais e volta para 1-RTT. Se não, marca o tíquete como usado e processa os dados iniciais. Para garantir a correção, todos os servidores de um cluster devem compartilhar o cache de tíquetes usados. O Redis com TTLs curtos (correspondentes ao período de validade dos tíquetes) é uma implementação comum. Sem esse mecanismo, o 0-RTT não é seguro para operações não idempotentes, como pagamentos.

A retomada com PSK do TLS 1.3 sem DHE não oferece sigilo de encaminhamento para a sessão retomada — se a PSK for comprometida posteriormente, todo o tráfego da sessão retomada poderá ser descriptografado. Para manter o sigilo de encaminhamento, o TLS 1.3 oferece suporte a PSK com DHE: o ClientHello inclui uma identidade PSK e um novo key_share. O servidor combina a PSK e o resultado de ECDHE para derivar as chaves da sessão. Mesmo que a PSK seja comprometida, a contribuição de ECDHE garante que o tráfego anterior permaneça protegido. A RFC 8446 recomenda PSK com DHE para todos os casos de retomada em que o sigilo de encaminhamento seja necessário.

O TLS 1.2 tinha mais de 300 combinações de conjuntos de cifras, muitas delas inseguras. O TLS 1.3 reduz esse número a 5 conjuntos de cifras, todos usando AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 e TLS_AES_128_CCM_8_SHA256. A troca de chaves e a autenticação são negociadas separadamente por meio das extensões supported_groups e signature_algorithms. Essa separação elimina a complexidade combinatória do TLS 1.2 e garante que toda conexão TLS 1.3 use criptografia autenticada.

Na prática, o 0-RTT é mais útil para conexões HTTP/2 nas quais o cliente repete uma solicitação GET (segura e idempotente) para um servidor visitado anteriormente. Os navegadores implementam o 0-RTT com cautela: o Chrome o habilita para métodos HTTP seguros; solicitações POST nunca são enviadas como dados de 0-RTT. O HTTP/3 sobre QUIC integra o TLS 1.3 nativamente — o 0-RTT do QUIC reutiliza o mecanismo do TLS 1.3. No QUIC, o 0-RTT também restaura os parâmetros de transporte (controle de fluxo e limites de fluxos) da sessão anterior, reduzindo ainda mais a sobrecarga de estabelecimento, além da camada TLS.

O TLS 1.3 inclui mecanismos para evitar ataques de rebaixamento de versão. O campo aleatório do ServerHello contém um valor sentinela quando o TLS 1.3 é negociado: os últimos 8 bytes recebem um valor fixo (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 para retorno ao TLS 1.2). Clientes compatíveis com TLS 1.3 verificam esse valor sentinela quando o servidor negocia o TLS 1.2, detectando tentativas ativas de rebaixamento. Além disso, o hash do histórico de mensagens de conclusão abrange todo o estabelecimento de conexão, incluindo a negociação da versão, portanto qualquer adulteração pode ser detectada. SCSV (valores de conjuntos de cifras de sinalização), como TLS_FALLBACK_SCSV, fornecem um sinal separado de rebaixamento para versões mais antigas do TLS.

A implantação do TLS 1.3 exige atenção a vários detalhes operacionais. As chaves de criptografia dos tíquetes de sessão precisam ser alternadas (normalmente a cada 24 horas) e sincronizadas entre os clusters de servidores para permitir a retomada em qualquer servidor. As chaves antigas de descriptografia dos tíquetes devem ser mantidas durante o período de validade dos tíquetes, para evitar falhas espúrias no estabelecimento de conexão. A anexação de OCSP é mais importante no TLS 1.3 (há uma ida e volta a menos para verificar o status do certificado). Os balanceadores de carga devem encaminhar o ClientHello do TLS 1.3 sem modificá-lo — alguns dispositivos intermediários antigos corrompem extensões desconhecidas, exigindo modos de compatibilidade.

Por que os dados iniciais de 0-RTT são vulneráveis a ataques de repetição no TLS 1.3?

O TLS 1.3 obtém estabelecimentos completos de conexão em 1-RTT e retomadas em 0-RTT por meio de tíquetes de sessão PSK. A derivação de chaves usa HKDF com uma sequência estruturada que produz chaves separadas para cada camada de tráfego. Os dados iniciais de 0-RTT eliminam uma ida e volta, mas são vulneráveis a repetições — uma ameaça mitigada por tíquetes de uso único e pela limitação do 0-RTT a operações idempotentes. PSK com DHE mantém o sigilo de encaminhamento durante a retomada. O TLS 1.3 restringe os conjuntos de cifras a 5 opções AEAD, eliminando combinações legadas inseguras. A prevenção do rebaixamento usa valores sentinela no campo aleatório do servidor.