O que e TLS 1.3? Tudo que Mudou

TLS 1.3 e a versão atual do protocolo Transport Layer Security, publicada como RFC 8446 em agosto de 2018. É um redesenho fundamental — não uma atualizacao incremental — que torna o HTTPS mais rápido, mais simples e mais seguro do que qualquer versão anterior.

Em 2026, 62% dos sites suportam TLS 1.3, e todos os principais navegadores o suportam desde 2018.

O que mudou do TLS 1.2

A filosofia de design: remover tudo que pode ser mal configurado. TLS 1.2 tem 37 conjuntos de cifras — alguns seguros, alguns quebrados. TLS 1.3 tem 5, todos seguros.

Os 5 conjuntos de cifras do TLS 1.3

TLS_AES_256_GCM_SHA384        ← Mais forte, mais comum
TLS_AES_128_GCM_SHA256        ← Amplamente usado, levemente mais rápido
TLS_CHACHA20_POLY1305_SHA256  ← Melhor para ARM/mobile (sem AES-NI)
TLS_AES_128_CCM_SHA256        ← IoT/embarcados
TLS_AES_128_CCM_8_SHA256      ← IoT/embarcados (tag curta)

Você não pode configura-los incorretamente — todos sao cifras AEAD com chaves fortes. Não ha risco de “habilitar acidentalmente uma cifra fraca” como no TLS 1.2.

Handshake 1-RTT: por que e mais rápido

Handshake TLS 1.2 (2 round trips):

Client → Server:  ClientHello (supported ciphers)
Server → Client:  ServerHello, Certificate, KeyExchange
Client → Server:  KeyExchange, ChangeCipherSpec, Finished
Server → Client:  ChangeCipherSpec, Finished
                  [4 messages before encrypted data flows]

Handshake TLS 1.3 (1 round trip):

Client → Server:  ClientHello + KeyShare
Server → Client:  ServerHello + KeyShare + Certificate + Finished
Client → Server:  Finished
                  [encrypted data can flow after 1 round trip]

O cliente envia seus parametros de compartilhamento de chave na primeira mensagem — sem necessidade de esperar o servidor especificar algoritmos primeiro. Isso reduz o handshake de 2 round trips para 1.

Retomada 0-RTT

Para visitantes que retornam (que já se conectaram antes), TLS 1.3 suporta 0-RTT — dados de aplicação criptografados enviados com a primeira mensagem:

Client → Server:  ClientHello + KeyShare + EarlyData (encrypted request)
Server → Client:  ServerHello + response

A requisição é enviada antes do handshake ser concluido. Tradeoff: dados 0-RTT sao vulneraveis a ataques de replay, entao devem ser usados apenas para requisições idempotentes (GET, não POST).

Sigilo antecipado obrigatório

No TLS 1.2, você podia usar troca de chaves RSA — a chave RSA de longo prazo do servidor descriptografa diretamente o pre-master secret. Se alguem gravar o trafego e posteriormente roubar a chave privada do servidor, pode descriptografar todas as conversas anteriores.

TLS 1.3 remove a troca de chaves RSA inteiramente. Toda troca de chaves usa Diffie-Hellman efemero (ECDHE) — um par de chaves único é gerado para cada conexão. Roubar a chave privada do servidor não ajuda a descriptografar sessões passadas. Mais sobre sigilo antecipado →

Certificado criptografado

No TLS 1.2, o certificado do servidor (incluindo o nome do domínio) é enviado em texto simples durante o handshake. Um observador passivo pode ver a qual site você esta se conectando.

No TLS 1.3, o certificado é enviado após as chaves do handshake serem derivadas — ele e criptografado. O SNI (Server Name Indication) ainda e visivel no TLS 1.3, mas o Encrypted Client Hello (ECH) também o criptografara no futuro.

Como habilitar TLS 1.3

Verifique se já esta habilitado

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 2>/dev/null | grep "Protocol"
# Expected: TLSv1.3

Nginx (1.13+ com OpenSSL 1.1.1+)

ssl_protocols TLSv1.2 TLSv1.3;

TLS 1.3 e habilitado por padrão no Nginx moderno — você só precisa não desabilita-lo.

Apache (2.4.37+ com OpenSSL 1.1.1+)

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Isso habilita TLS 1.2 e 1.3.

Verifique sua versão do OpenSSL

openssl version
# Needs: OpenSSL 1.1.1+ for TLS 1.3 support

Se seu OpenSSL e mais antigo, atualize-o ou atualize seu SO.

Devo forcar apenas TLS 1.3?

Ainda não. Cerca de 38% dos sites não suportam TLS 1.3, e alguns clientes (proxies corporativos, Java 8, sistemas embarcados mais antigos) suportam apenas TLS 1.2. Remover TLS 1.2 hoje bloquearia alguns usuarios.

Configuração recomendada: Suporte tanto TLS 1.2 quanto 1.3. Isso fornece a velocidade do TLS 1.3 para clientes modernos enquanto mantem a compatibilidade. E isso que Google, Cloudflare e a maioria dos grandes sites fazem.

Perguntas frequentes

Preciso de um novo certificado para TLS 1.3?

Não. O mesmo certificado funciona com TLS 1.2 e 1.3. Certificados sao agnosticos ao protocolo — eles contem uma chave pública e assinatura da CA, independentemente de qual versão do TLS os usa.

TLS 1.3 afeta o desempenho?

Sim, positivamente. O handshake de 1-RTT economiza 50-100ms na primeira conexão. A retomada 0-RTT elimina a latencia do handshake inteiramente para visitantes que retornam. Combinado com HTTP/2 (que requer HTTPS), sites com TLS 1.3 sao mensuravelmente mais rapidos.

TLS 1.2 ainda e seguro?

Sim, com conjuntos de cifras AEAD (AES-GCM, ChaCha20-Poly1305) e troca de chaves ECDHE. Evite cifras CBC no TLS 1.2 — elas foram vulneraveis a ataques (BEAST, Lucky13). TLS 1.3 e melhor, mas TLS 1.2 com cifras modernas permanece seguro.

E quanto ao TLS 1.4?

Não ha TLS 1.4 planejado. O IETF considera o TLS 1.3 o alvo para o futuro previsivel. A proxima grande mudança será incorporar troca de chaves pos-quantica (ML-KEM) como hibrido com ECDHE existente — isso acontecera dentro do TLS 1.3, não como uma nova versão.