Forward secrecy (também chamado Perfect Forward Secrecy / PFS) é uma propriedade de uma conexão TLS que garante: mesmo que a chave privada do servidor seja comprometida no futuro, comunicações criptografadas passadas não podem ser descriptografadas.
Funciona gerando uma chave única e efêmera para cada conexão. Após o término da conexão, a chave efêmera é descartada. Ninguém — nem mesmo o proprietário do servidor — pode recriá-la.
Por que forward secrecy importa
Sem forward secrecy (troca de chaves RSA)
Atacante grava tráfego criptografado hoje
↓
Anos depois, atacante rouba a chave privada RSA do servidor
↓
Atacante descriptografa TODO o tráfego gravado — senhas, mensagens, tudoCom troca de chaves RSA estática (TLS 1.2 sem ECDHE), a mesma chave privada do servidor é usada para descriptografar cada sessão. Se essa chave for roubada, toda conversa passada é exposta.
Com forward secrecy (troca de chaves ECDHE)
Atacante grava tráfego criptografado hoje
↓
Anos depois, atacante rouba a chave privada do servidor
↓
Não consegue descriptografar tráfego passado — cada sessão usou uma chave
efêmera única que foi descartada após o término da sessãoCada conexão gera um par de chaves Diffie-Hellman fresco, computa uma chave de sessão única e destrói a chave efêmera quando termina. A chave privada de longo prazo do servidor é usada apenas para autenticação (provar identidade), não para troca de chaves (derivar a chave de criptografia).
Como funciona tecnicamente
- Cliente e servidor geram cada um um par de chaves ECDHE efêmero (aleatório, por conexão)
- Eles trocam as metades públicas dessas chaves efêmeras
- Ambos calculam o mesmo segredo compartilhado usando sua própria chave efêmera privada + a chave pública efêmera do outro (esta é a matemática Diffie-Hellman)
- O segredo compartilhado deriva a chave de sessão usada para criptografia AES
- As chaves efêmeras são descartadas após a chave de sessão ser derivada
A chave privada do certificado do servidor é usada apenas para assinar as mensagens do handshake — provando que o servidor é genuíno. Nunca é usada para descriptografar tráfego.
Forward secrecy nas versões TLS
| Versão TLS | Forward secrecy | Notas |
|---|---|---|
| SSL 3.0 | ❌ Não disponível | Troca de chaves apenas RSA |
| TLS 1.0 | ⚠️ Opcional | ECDHE suportado mas não obrigatório |
| TLS 1.1 | ⚠️ Opcional | Mesmo que TLS 1.0 |
| TLS 1.2 | ⚠️ Opcional (mas recomendado) | Depende do cipher suite — ECDHE = sim, RSA = não |
| TLS 1.3 | ✅ Obrigatório | Troca de chaves RSA removida completamente |
O TLS 1.3 resolveu isso removendo a troca de chaves RSA — todas as conexões TLS 1.3 têm forward secrecy por padrão. Sem necessidade de configuração.
Como verificar se seu servidor tem forward secrecy
# Verificar qual troca de chaves seu servidor usa
echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | grep -E "Server Temp Key|Protocol"Procure por:
Server Temp Key: ECDH, P-256→ ✅ Forward secrecy (ECDHE)Server Temp Key: X25519→ ✅ Forward secrecy- Sem linha
Server Temp Key→ ❌ Troca de chaves RSA, sem forward secrecy
Garantindo forward secrecy no TLS 1.2
Nginx:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
ssl_prefer_server_ciphers off;Todos os cipher suites começam com ECDHE — troca de chaves efêmera.
Apache:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder offRelevância no mundo real
Forward secrecy protege contra:
- Vigilância estatal — governos gravando tráfego criptografado agora, esperando descriptografar depois quando adquirirem as chaves (por ordens judiciais, hacking ou computação quântica)
- Comprometimento de servidor — se um atacante roubar a chave privada do servidor, ele só pode se passar pelo servidor dali em diante, não descriptografar tráfego passado
- Vazamento de chaves — exposição acidental de chaves privadas (ex.: commitadas no Git, incluídas em backup)
É por isso que a Let’s Encrypt recomenda certificados ECDSA — eles se combinam naturalmente com troca de chaves ECDHE para um handshake completamente baseado em curvas elípticas.
Perguntas frequentes
Meu certificado SSL precisa suportar forward secrecy?
O certificado em si não determina o forward secrecy — o cipher suite determina. Qualquer certificado (RSA ou ECDSA) funciona com troca de chaves ECDHE. Mas certificados ECDSA se combinam mais naturalmente com ECDHE (ambos usam curvas elípticas), resultando em um handshake mais rápido.
O forward secrecy está habilitado por padrão?
No TLS 1.3: sempre — é obrigatório. No TLS 1.2: depende da configuração do seu servidor. Os padrões modernos (Nginx, Apache) preferem cipher suites ECDHE, mas configurações mais antigas podem ainda permitir troca de chaves RSA.
O forward secrecy deixa as coisas mais lentas?
De forma negligível. A troca de chaves ECDHE adiciona ~1ms ao handshake em hardware moderno. O benefício de segurança supera em muito o custo.
E o modo 0-RTT no TLS 1.3?
0-RTT (retomada sem ida e volta) é um caso especial. Os dados iniciais enviados em 0-RTT não têm forward secrecy contra comprometimento de servidor (o PSK usado para retomada é derivado das chaves da sessão anterior). É por isso que 0-RTT deve ser usado apenas para requisições seguras e idempotentes.