TLS 1.2 vs TLS 1.3: o que mudou e o que configurar

TLS 1.2 vs TLS 1.3 já não é uma escolha entre iguais. O TLS 1.2 (RFC 5246, 2008) é seguro quando restrito à troca de chaves ECDHE e a cipher suites AEAD; o TLS 1.3 (RFC 8446 em 2018, revisado como RFC 9846 em julho de 2026) torna isso a única opção, criptografa uma parte maior do handshake e é a única versão que oferece troca de chaves híbrida pós-quântica e Encrypted Client Hello.

Visão geral

O handshake

O TLS 1.2 negocia primeiro e troca as chaves depois: o cliente lista as cipher suites, o servidor escolhe uma e envia o certificado e os parâmetros da troca de chaves, o cliente envia o key share dele e os dois concluem o handshake. Passam-se duas idas e voltas antes que os dados da aplicação comecem a fluir, e o certificado trafega em claro. Com suítes de RSA estático, o cliente criptografa o premaster secret com a chave do certificado do servidor, então qualquer pessoa que obtenha essa chave mais tarde consegue descriptografar todas as sessões gravadas.

O TLS 1.3 aposta em um palpite: o cliente envia key shares dos grupos que prefere já na primeira mensagem, o servidor responde com o key share dele e, logo em seguida, com as extensões criptografadas, o certificado, CertificateVerify e Finished, e o cliente pode enviar dados depois de uma ida e volta. Sessões retomadas podem até levar dados 0-RTT (early data), ao custo da proteção contra repetição desses dados.

O script abaixo, executado com o OpenSSL 3.6.5 contra um servidor público em 20 de outubro de 2026, mostra o resultado prático quando o mesmo cliente força cada uma das versões.

#!/bin/sh
host=${1:-cloudflare.com}
for version in -tls1_2 -tls1_3; do
  echo "== $version"
  echo | openssl s_client -connect "$host:443" -servername "$host" "$version" -brief 2>&1 \
    | grep -E "Protocol version|Ciphersuite|Peer Temp Key|Negotiated TLS1.3 group"
done

== -tls1_2
Protocol version: TLSv1.2
Ciphersuite: ECDHE-ECDSA-CHACHA20-POLY1305
Peer Temp Key: X25519, 253 bits
== -tls1_3
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Negotiated TLS1.3 group: X25519MLKEM768

A conexão TLS 1.2 é segura aqui porque o servidor só permite ECDHE com AEAD, mas fica limitada ao X25519 clássico; a conexão TLS 1.3 negocia o híbrido pós-quântico.

O que o TLS 1.3 removeu, e por quê

Quase todos os ataques famosos ao TLS dos anos 2010 exploraram um recurso da era do TLS 1.2 que o TLS 1.3 eliminou:

• Modo CBC com MAC-then-encrypt (BEAST, Lucky Thirteen, POODLE): só restam cifras AEAD.
• RC4 (vieses estatísticos) e 3DES (SWEET32): removidos.
• Transporte de chave RSA (padding oracles de Bleichenbacher, ROBOT; sem forward secrecy): removido.
• Grupos de campo finito de exportação ou arbitrários (FREAK, Logjam): só restam named groups.
• Renegociação e compressão (triple handshake, CRIME): removidas.
• Assinaturas sobre transcrições parciais (o ServerKeyExchange do TLS 1.2 assina só os parâmetros): o CertificateVerify assina a transcrição inteira.
• SHA-1 e MD5 em assinaturas: removidos.

A RFC 9846 também endurece os requisitos para as implementações do TLS 1.2, e a RFC 9325 lista o subconjunto seguro do TLS 1.2: ECDHE ou DHE com AEAD, extended master secret (RFC 7627) e renegociação segura.

Recursos que só o TLS 1.3 oferece

• Troca de chaves híbrida pós-quântica (X25519MLKEM768, RFC 10024), negociada por padrão nos principais navegadores desde o fim de 2024 e no OpenSSL desde a 3.5.
• Encrypted Client Hello (RFC 9849), que esconde da rede o nome do servidor quando usado com registros DNS HTTPS.
• Compressão de certificados (RFC 8879) e credenciais delegadas (RFC 9345).
• QUIC, que incorpora o handshake do TLS 1.3 e é o transporte do HTTP/3.

Conformidade e políticas

• Sistemas federais dos EUA: o NIST SP 800-52 Rev. 2 exige que os servidores TLS do governo ofereçam suporte ao TLS 1.3 até 1º de janeiro de 2024 e permite o TLS 1.2 com suítes aprovadas.
• Ambientes de cartões de pagamento: o PCI DSS proíbe o SSL e as versões iniciais do TLS (1.0) desde 30 de junho de 2018; o TLS 1.2 e o 1.3 são ambos aceitáveis.
• IETF: a RFC 8996 descontinuou o TLS 1.0 e o 1.1 em 2021; os navegadores os removeram em 2020.
• Planos pós-quânticos: o NIST IR 8547 (rascunho) e o CNSA 2.0 pressupõem estabelecimento de chaves híbrido ou pós-quântico, que só está disponível no TLS 1.3.

Quando escolher cada um

• Sites e APIs públicos: TLS 1.3 de preferência, com o TLS 1.2 no subconjunto seguro como alternativa.
• Serviços internos, service meshes, mTLS: só TLS 1.3.
• Clientes legados (Android antigo, dispositivos embarcados, versões mais antigas do Java e do Windows): TLS 1.2 com ECDHE e AEAD; planeje a aposentadoria deles.
• Equipamentos intermediários (middleboxes) que inspecionam o tráfego: parta do princípio de que eles vão precisar de atualizações para o TLS 1.3, o ECH e os ClientHellos pós-quânticos grandes, em vez de segurar os servidores por causa deles.
• Tudo o que precisa de confidencialidade pós-quântica: TLS 1.3 com um grupo híbrido.

Notas de migração

1. Atualize a biblioteca TLS: OpenSSL 1.1.1 ou posterior para o TLS 1.3, 3.5 ou posterior para os grupos pós-quânticos por padrão; BoringSSL atual, Go, Java 11 ou posterior, Windows Server 2022 ou posterior.
2. Ative o TLS 1.3 junto com o 1.2 e depois restrinja o 1.2 a suítes com ECDHE e AEAD; no nginx, ssl_protocols TLSv1.2 TLSv1.3; com uma lista ssl_ciphers curta, já que as suítes do TLS 1.3 são configuradas à parte.
3. Verifique certificados e chaves: certificados RSA funcionam com o TLS 1.3 porque as assinaturas do handshake usam PSS com as mesmas chaves; certificados ECDSA funcionam sem alterações.
4. Decida sobre o 0-RTT: deixe-o desativado, a menos que a aplicação consiga lidar com segurança com repetições das requisições antecipadas.
5. Meça o tráfego TLS 1.2 que resta e marque uma data para desativá-lo onde ele chegar a zero. O gerador de configuração TLS produz configurações para os servidores mais comuns, e o verificador de domínios em lote informa quais versões seus hosts aceitam.

Referências

• RFC 9846, TLS 1.3 (§1.3, diferenças em relação ao TLS 1.2; §1.4, atualizações que afetam o TLS 1.2)
• RFC 5246, TLS 1.2
• RFC 9325, recomendações para o uso seguro de TLS e DTLS
• RFC 8996, descontinuação do TLS 1.0 e do TLS 1.1
• RFC 10024, acordo de chaves ML-KEM híbrido para TLS 1.3
• RFC 9849, TLS Encrypted Client Hello
• NIST SP 800-52 Rev. 2
• PCI SSC: migração do SSL e das versões iniciais do TLS