La Perfect Forward Secrecy (PFS, o semplicemente forward secrecy) è una proprietà crittografica di un protocollo di scambio di chiavi che garantisce che la compromissione della chiave privata a lungo termine di un server non permetta a un avversario di decifrare le sessioni di comunicazione passate che aveva intercettato e registrato. In altre parole: anche se un attaccante cattura tutto il traffico TLS di un server oggi, e poi tra cinque anni ottiene la chiave privata del server (tramite breach, sequestro, exploit), non potrà decifrare retroattivamente le sessioni passate.
Il problema senza forward secrecy
Nel vecchio modello TLS 1.2 con RSA key exchange, lo schema era:
- Il client genera un pre-master secret casuale
- Lo cifra con la chiave pubblica RSA del server
- Lo invia al server
- Il server lo decifra con la chiave privata RSA — la stessa chiave a lungo termine usata per tutte le sessioni
Chiunque abbia registrato il traffico TLS cifrato può decifrarlo retroattivamente se ottiene la chiave privata RSA del server — che è statica e potenzialmente usata per anni. Questo è il modello harvest now, decrypt later applicato al traffico TLS: agenzie di intelligence che registrano traffico cifrato oggi per decifrarlo quando ottengono le chiavi.
Come funziona la forward secrecy
La forward secrecy si ottiene usando uno scambio di chiavi effimero (ECDHE o DHE): per ogni sessione TLS vengono generate nuove coppie di chiavi Diffie-Hellman usa-e-getta, usate per derivare la chiave di sessione e poi immediatamente scartate.
Il segreto di sessione dipende da queste chiavi effimere — non dalla chiave privata RSA/ECDSA del certificato. La chiave privata del certificato serve solo per autenticare il server (firma del CertificateVerify nel TLS handshake), non per derivare il segreto di sessione. Quindi:
- Chiave privata del server compromessa → l’attaccante può impersonare il server in futuro, ma non può decifrare le sessioni passate (le chiavi effimere sono già state scartate)
- Le chiavi di sessione passate non sono mai esistite al di fuori della memoria RAM del server durante quella sessione
TLS 1.3 e forward secrecy obbligatoria
In TLS 1.3, la forward secrecy è obbligatoria: le suite RSA key exchange (senza ECDHE) sono state completamente rimosse dallo standard. L’unico meccanismo di scambio di chiavi ammesso è ECDHE (o DHE), quindi ogni sessione TLS 1.3 gode automaticamente di forward secrecy.
In TLS 1.2, la forward secrecy è opzionale e dipende dalla suite crittografica negoziata. Le suite con forward secrecy hanno DHE o ECDHE nel nome (es. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384); quelle senza (es. TLS_RSA_WITH_AES_256_CBC_SHA) non la garantiscono e dovrebbero essere disabilitate nelle configurazioni sicure.
Forward secrecy e logging TLS
La forward secrecy ha implicazioni operative significative: le sessioni TLS non possono essere decifrate a posteriori nemmeno dall’amministratore del server. Questo crea tensione con:
- Network monitoring / DLP: le soluzioni di ispezione TLS che decifrano il traffico per analizzarlo devono terminare le sessioni TLS sul proxy, perdendo la forward secrecy end-to-end.
- Debug e forensica: non è possibile decifrare sessioni TLS passate con sola chiave privata; serve la chiave di sessione, esportabile solo con configurazioni di debug attive (
SSLKEYLOGFILEin Firefox/Chrome durante la sessione).
Relazione con altri concetti
La forward secrecy è uno dei requisiti della crittografia end-to-end robusta: il Signal Protocol estende il concetto con il Double Ratchet, che garantisce forward secrecy a livello di singolo messaggio — non solo di sessione.