A pergunta que a forward secrecy responde

Imagine que um atacante grava hoje o seu tráfego criptografado e guarda tudo. Meses depois, ele consegue a chave privada de longo prazo do servidor, talvez por um vazamento, talvez por uma ordem judicial. Com essa chave, ele consegue voltar e descriptografar o tráfego que capturou?

Se a resposta for não, a conexão tinha forward secrecy (sigilo futuro), também chamada de perfect forward secrecy. Se for sim, não tinha. A diferença depende só da troca de chaves indicada na cipher suite (a suíte de cifras), e é por isso que essa é uma das primeiras informações que o decodificador mostra.

RSA estático: prático, mas frágil

Na antiga troca de chaves com estático, o cliente escolhe o segredo que vai proteger a sessão, criptografa esse segredo com a chave pública que vem no certificado do servidor e o envia. Só a chave privada do servidor consegue descriptografá-lo; então, naquele momento, a sessão fica protegida de quem estiver escutando.

O problema fatal é que o segredo da sessão ficou protegido pela chave de longo prazo do servidor. Se essa chave vazar algum dia, toda sessão passada que dependeu dela pode ser aberta a partir de uma gravação, porque o segredo criptografado está ali mesmo, dentro do handshake capturado. Comprometer uma única chave quebra, de forma retroativa, todas as conversas que ela já protegeu. As suítes que começam com TLS_RSA_WITH_ funcionam assim, e o decodificador as marca como suítes sem forward secrecy.

Diffie-Hellman efêmero: a solução

O efêmero corta a ligação entre o segredo da sessão e qualquer chave de longo prazo. A cada conexão, os dois lados geram pares de chaves Diffie-Hellman novos e descartáveis, trocam as metades públicas, e cada lado combina a própria metade privada com a metade pública do outro; assim, os dois chegam ao mesmo segredo compartilhado. As metades privadas nunca saem das máquinas e são descartadas quando a conexão termina.

Como o segredo compartilhado nunca foi criptografado com a chave de longo prazo do servidor, e as chaves privadas efêmeras já não existem, um comprometimento posterior da chave de longo prazo não revela nada sobre as sessões passadas. Simplesmente não há nada na gravação para abrir.

Isso aparece como ECDHE, o Diffie-Hellman efêmero de curva elíptica, ou como DHE, a variante mais antiga, de corpo finito. O é mais rápido e é o padrão moderno; o está sendo aposentado, e é por isso que até uma suíte DHE- forte, como a TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, hoje leva a flag discouraged (desaconselhada) da . Os primos estáticos, não efêmeros, ECDH (Elliptic-Curve Diffie-Hellman) e DH, sem o E no final, não oferecem forward secrecy.

Autenticação é outra tarefa

Uma confusão comum é achar que tirar o RSA estático significa tirar o RSA. Não significa. Troca de chaves e autenticação são duas tarefas diferentes, e o nome da suíte mostra cada uma separadamente.

Em TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, o ECDHE faz a troca de chaves e o RSA faz a autenticação: o servidor assina os valores efêmeros do handshake com a chave privada que corresponde ao seu certificado RSA e, assim, prova que é o dono legítimo dele. O segredo da sessão vem da troca Diffie-Hellman efêmera, então a forward secrecy continua valendo, e o certificado continua provando a identidade. O artigo sobre a anatomia dos certificados explica como funciona essa ligação com a identidade.

Por que o TLS 1.3 tornou a forward secrecy obrigatória

O TLS 1.3 encerrou a questão ao tirar do protocolo, por completo, o transporte de chave com RSA estático. Toda troca de chaves do TLS 1.3 é efêmera; então a forward secrecy deixou de ser algo que você garante escolhendo a suíte certa, porque agora quem garante é o próprio protocolo. RSA e continuam existindo, mas só como algoritmos de assinatura, para a autenticação. É também por isso que o nome de uma suíte do TLS 1.3 não tem nenhum trecho de troca de chaves: não existe mais nenhuma opção sem forward secrecy para indicar.

Coletar agora, decifrar depois

A forward secrecy protege contra o comprometimento de uma chave que acontece depois, mas parte do princípio de que a matemática do Diffie-Hellman continua difícil de resolver. A preocupação que está no horizonte é um futuro computador quântico capaz de quebrar as trocas de chaves de curva elíptica usadas hoje, e isso dá ao tráfego gravado uma vida útil longa para o atacante que estiver disposto a esperar. Essa é a ameaça do harvest now, decrypt later (coletar agora, decifrar depois), e é ela que está puxando a migração para trocas de chaves híbridas pós-quânticas, que fazem ao mesmo tempo uma troca clássica e uma troca resistente à computação quântica. A forward secrecy continua necessária; só deixou de ser considerada suficiente para sempre.

Fontes

Que o TLS 1.3 tornou o sigilo futuro obrigatório em vez de opcional é uma mudança de protocolo, não uma preferência de configuração, e a especificação afirma isso diretamente.