Perfect Forward Secrecy (PFS)
Summary
- Each session uses unique ephemeral keys
- Past sessions cannot be decrypted even if the server's private key is later compromised
- Requires ECDHE or DHE key exchange algorithms
- Mandatory in TLS 1.3, optional in TLS 1.2
- Critical for protecting long-lived data against future key compromise
The Importance of PFS
Without forward secrecy, an attacker who records encrypted traffic and later obtains the server's private key can decrypt all past communications. This is a realistic threat: intelligence agencies are known to record encrypted traffic at scale for potential future decryption, and private keys can be obtained through server compromise, legal compulsion, or cryptographic breakthroughs.
PFS is achieved by using ephemeral Diffie-Hellman (DHE) or ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange instead of static RSA key exchange. With ECDHE, each connection generates a unique key pair that is discarded after the session ends. Even with the server's private key, there is no way to derive these ephemeral session keys.
TLS 1.3 mandates forward secrecy by only allowing ECDHE-based key exchange, eliminating static RSA entirely. For TLS 1.2, you must configure your server to prefer ECDHE cipher suites and disable static RSA key exchange to get PFS. All modern browsers support ECDHE, so there is no compatibility cost.
How to Check
An SSL checker reports whether your server's cipher suites provide forward secrecy. Look for cipher suites containing "ECDHE" or "DHE" in their names. Suites with just "RSA" for key exchange do not provide forward secrecy and should be disabled.