Perfect Forward Secrecy: Why a Leaked Key Does Not Expose Past Traffic

Q: How do I know if my server lacks forward secrecy?

If the server offers cipher suites without ECDHE (or DHE) in the name, a connection can end up without forward secrecy. Use TLS 1.3 or restrict 1.2 to ECDHE ciphers only to guarantee it.

Imagine an attacker records all of your encrypted traffic today and stores it. A year later your server's private key leaks. Without forward secrecy, all that past traffic can now be decrypted at once. With forward secrecy, it stays safe. Here is why — and how to make sure your connections have it.

Short answer

Perfect Forward Secrecy (PFS, also just "forward secrecy") means that compromising the server's long-term private key cannot be used to decrypt previously recorded traffic. It is achieved by having each connection agree on a unique, temporary (ephemeral) key via Diffie-Hellman — typically ECDHE — which is discarded afterwards and never derived from the private key. In TLS 1.3 forward secrecy is mandatory; in TLS 1.2 it must be actively chosen.

The problem without forward secrecy

In the old static RSA key exchange, the client used the server's public key to encrypt the shared secret. That means the entire confidentiality of the session rests on the server's private key. If an attacker gets hold of that key — via a breach, a court order or a vulnerability like Heartbleed — all previously recorded traffic can be decrypted retroactively. This is called a "harvest now, decrypt later" attack, and it is a real threat for long-lived private keys.

How ephemeral key exchange solves it

With ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) each side generates a new, temporary key pair for every connection. They exchange the public parts and each independently computes the same shared secret — without the secret ever being sent, and without it depending on the server's long-term key. When the connection closes, the ephemeral keys are discarded. The server's private key is used only to sign the handshake (prove identity), not to protect the secret. The full walkthrough of key exchange is in the TLS handshake explained.

Static vs ephemeral key exchange

Property	Static RSA	ECDHE (ephemeral)
Key per connection	Same private key	New ephemeral key
Forward secrecy	No	Yes
Leaked key exposes past traffic	Yes	No

How to ensure forward secrecy

Use TLS 1.3 — all of its cipher suites require forward secrecy, so there is nothing to configure here. On TLS 1.2 you must allow ECDHE ciphers and not the old static RSA ones:

# nginx — ECDHE-based 1.2 ciphers only (all have forward secrecy)
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;

Cipher suites without ECDHE (e.g. AES256-GCM-SHA384 with no prefix) use static key exchange and do not have forward secrecy. What the individual parts of a cipher suite mean is explained in what is a cipher suite.

Verify that a connection has forward secrecy

openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | grep -E "Protocol|Cipher"

If you see TLSv1.3, you always have forward secrecy. On 1.2 the cipher name must contain ECDHE. A name without ECDHE means that specific connection lacks forward secrecy.

How CertControl helps

Forward secrecy is easy to lose to a misconfiguration — a single server still offering static RSA ciphers is enough. CertControl negotiates a real handshake against each endpoint, reports the chosen cipher suite, and flags endpoints that lack forward secrecy, so you can ensure it consistently across your whole estate.

Frequently asked questions

What is "harvest now, decrypt later"?

An attack where you record encrypted traffic today and store it, hoping to obtain the key later — via a breach or future compute power. Forward secrecy defeats it, because each session has a unique ephemeral key that cannot be derived from the leaked private key.

Does TLS 1.3 always have forward secrecy?

Yes. All TLS 1.3 cipher suites require ephemeral key exchange, so every TLS 1.3 connection has forward secrecy. Removing the static alternatives entirely was a deliberate design decision.

What is the difference between DHE and ECDHE?

Both are ephemeral Diffie-Hellman and provide forward secrecy. ECDHE uses elliptic curves, which is faster and needs shorter keys for the same security. ECDHE is the default choice today.

Does forward secrecy cost performance?

Marginally, because a new key pair is generated per connection. With ECDHE and modern hardware the cost is negligible and fully outweighed by the security benefit. Session resumption reduces it further.

How do I know if my server lacks forward secrecy?

If the server offers cipher suites without ECDHE (or DHE) in the name, a connection can end up without forward secrecy. Use TLS 1.3 or restrict 1.2 to ECDHE ciphers only to guarantee it.

See the platform Book a demo

What is Perfect Forward Secrecy?