Back to Demos
9/52
FundamentalsAdvanced
Perfect Forward Secrecy
Learn how PFS protects past sessions even if the server's private key is compromised. See ECDHE in action.
Interactive Demo
Forward Secrecy Deep Dive
Why losing your private key shouldn't mean losing all your past communications
Step 0 of 8
Introduction: Why Forward Secrecy matters
NOW VIEWING
The Problem Forward Secrecy Solves
Key Insight
Forward secrecy means your secrets today stay secret even if your keys are compromised tomorrow. The "forward" refers to time — past sessions are protected going forward.
Without Forward Secrecy
January 2023
Alice
══ Encrypted ══▶
Bank
Uses bank's public key to encrypt
Attacker records all traffic
December 2024
PRIVATE KEY STOLEN!
Attacker now decrypts:
• Every transaction
• Every password
• Everything. Forever.
With Forward Secrecy
January 2023
Alice
══ Encrypted ══▶
Bank
Ephemeral key exchange - new keys each session!
Attacker records all traffic
December 2024
PRIVATE KEY STOLEN!
Past traffic STILL encrypted!
• Session keys were ephemeral
• Keys never stored anywhere
• Only current sessions at risk
RSA Key Exchange (No Forward Secrecy)
Step 1: Server has long-term RSA key pair
Private Key (same for years)
Public Key (in certificate)
Step 2: Client generates pre-master secret (PMS)
PMS = random_bytes(48)
Step 3-4: Client encrypts PMS with public key, Server decrypts
Client
─── Encrypt(PMS) ───▶
Server
THE PROBLEM
The encrypted PMS is in the recorded traffic!
If attacker gets the private key later, they can:
- Find encrypted PMS in recorded traffic
- Decrypt PMS using stolen private key
- Derive session key
- Decrypt EVERYTHING
ECDHE Key Exchange (With Forward Secrecy)
Step 1: Both sides generate EPHEMERAL key pairs
Client
Private: a
Public: A = aG
(temporary!)
Public: A = aG
(temporary!)
Server
Private: b
Public: B = bG
(temporary!)
Public: B = bG
(temporary!)
Step 2: Exchange public ephemeral keys
Client (A)
◄─── Exchange ───▶
Server (B)
Step 3: Each computes SAME shared secret
Client computes:
a × B = a × bG = abG
Server computes:
b × A = b × aG = abG
↑ SAME SECRET! ↑
Step 5: DISCARD ephemeral private keys
Keys 'a' and 'b' are deleted immediately. Gone forever. Never stored.
THE PROTECTION
Attacker records A and B from traffic, but:
- Computing 'abG' from 'aG' and 'bG' requires knowing 'a' or 'b'
- Even with server's long-term private key: can't compute ephemeral secrets
- Each session = unique keys = unique secret
Key Exchange Methods Comparison
| Method | Forward Secrecy | How It Works | Rating |
|---|---|---|---|
| ECDHE | Elliptic curve ephemeral DH | Best | |
| DHE | Classic DH ephemeral (2048+ bit) | Good | |
| ECDH | Static EC keys (reused) | Avoid | |
| DH | Static DH keys (reused) | Avoid | |
| RSA | Encrypt with server's public key | Bad |
The "E" is Everything!
ECDH=Static keys
ECDHE=Ephemeral keys
DH=Static keys
DHE=Ephemeral keys
↑ This letter means forward secrecy!
Who Wants Your Past Traffic?
Governments / Intelligence
"Collect now, decrypt later" — Store encrypted traffic for years, wait for key compromise or quantum computers
Corporate Espionage
Record competitor communications, hope for breach that reveals keys
Malicious Insiders
Copy traffic while employed, steal keys when leaving
Legal Discovery
Subpoena for private keys, retroactively read communications
"Collect Now, Decrypt Later" Strategy
- Tap internet backbone
- Store ALL encrypted traffic (storage is cheap)
- Wait for: key theft, legal compulsion, or quantum computers
- Decrypt historical communications
Forward Secrecy Response
- Ephemeral keys were never stored
- Session secrets can't be reconstructed
- Past traffic remains encrypted forever
Check Forward Secrecy Status
OpenSSL Check
# Check if server supports ECDHE openssl s_client -connect yoursite.com:443 2>/dev/null | grep -E "Server Temp Key|Cipher" # Good output (forward secrecy): Server Temp Key: ECDH, P-256, 256 bits ← Ephemeral! Cipher: ECDHE-RSA-AES256-GCM-SHA384 ← ECDHE = good # Bad output (no forward secrecy): Cipher: AES256-SHA256 ← No ECDHE = bad
SSL Labs Test
Go to: https://www.ssllabs.com/ssltest/
"Forward Secrecy: Yes (with most browsers)"
TLS_ECDHE_* ciphers listed first
TLS_RSA_* ciphers = no forward secrecy
Enable Forward Secrecy
Nginx Configuration
# Prioritize ECDHE ciphers ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_cipher_order on;
Apache Configuration
SSLProtocol -all +TLSv1.2 +TLSv1.3 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 SSLHonorCipherOrder on
TLS 1.3: Forward Secrecy by Default
Good News!
- TLS 1.3 REQUIRES forward secrecy
- No RSA key exchange in TLS 1.3
- You can't turn it off
Simple Config
ssl_protocols TLSv1.3; # Done! Forward secrecy guaranteed.
Adoption Timeline
2011Firesheep attack → Google enables FS
2013Snowden revelations → "Collect now, decrypt later" confirmed
2015Major browsers prefer ECDHE
2018TLS 1.3 published → FS mandatory
2024~95% of HTTPS uses forward secrecy
Forward Secrecy Checklist
Server supports TLS 1.3 (FS automatic)
Server prioritizes ECDHE/DHE cipher suites
RSA key exchange disabled or lowest priority
SSL Labs shows "Forward Secrecy: Yes"
If all checked: Your past traffic is protected!
RSA = No Forward Secrecy
ECDHE = Forward Secrecy
E = Ephemeral = Protected
Read the Complete Forward Secrecy Guide
Learn how ephemeral keys protect your past communications even if keys are compromised