Perfect forward secrecy

An adversary recording encrypted traffic now and obtaining the server key later — through a breach, a compulsion, or a flaw in how the key was stored.

Without forward secrecy, that key decrypts every recorded session retroactively, including ones from years earlier.

With it, each session used a key that existed only for that session and was discarded, so there is nothing for the long-term key to unlock.

It does not protect a session being attacked in real time by someone holding the key, which is a different and more visible situation.

Nor does it help if the endpoints themselves are compromised, since the plaintext is there regardless.

Both sides generate temporary key material for the session and use it to derive a shared secret neither transmitted.

The certificate's long-term key is used only to sign that exchange, proving the server is who it claims to be.

So the certificate authenticates and the ephemeral exchange encrypts, which is the separation the property depends on.

Older key-exchange methods used the certificate key directly to protect the session secret, which is exactly what makes recorded traffic decryptable later.

The ephemeral material is discarded when the session ends, and a server that keeps session tickets for too long weakens the guarantee it just provided.

The current version of TLS removed the non-forward-secret key exchanges entirely, so every connection using it has the property by construction.

On the previous version it depended on the cipher suites the server offered and preferred, which is where configuration used to matter.

A server still offering the older version therefore needs its suite ordering checked; one that only offers the current version does not.

Which means the practical question has shifted from whether forward secrecy is enabled to whether obsolete protocol versions are still accepted.

Session resumption lets a returning client skip a full handshake, which is a real performance benefit.

It works by encrypting the session state under a separate key held by the server, which becomes a long-lived secret protecting many sessions.

A server rotating that key infrequently recreates the situation forward secrecy was meant to remove.

Which is why rotation frequency matters, and why it is a server-side operational detail that no external observation can see.

The protocol versions the server accepts are recorded, which is now the strongest signal about whether forward secrecy applies.

The cipher suites offered are read, which is what decides the property on the older protocol version.

The certificate and its key are examined separately, since the certificate is about authentication rather than about this property.

Session ticket key rotation is a server-side configuration and is not observable from outside.