Forward secrecy: why yesterday stays private

What it protects against

It protects against one specific attack, and the protection is narrower than the confident name suggests.

The attack is simply stated: capture now, decrypt later. Storage is cheap enough that recorded traffic can wait years for a key to leak, be seized under legal process, or eventually be broken. Without forward secrecy, a single key compromise turns every recorded conversation protected by it into readable text, retroactively and all at once.

With it, each conversation used keys that existed only for that conversation, derived over the TLS handshake from material both sides contributed and then discarded. The long-term key proves identity; it does not encrypt anything that could be replayed against the archive.

How the separation works

Two jobs that used to be handled by a single key, now split apart between two of them.

The certificate's RSA or elliptic-curve key answers "is this really the server for this name", which is the identity half of the handshake described on the handshake page. The session keys answer "what protects the next few minutes of traffic", and they are computed fresh from contributions both sides make and neither stores.

That split is why the property exists at all. An attacker holding the long-term key can impersonate the server going forward, which is serious in its own right, but cannot go back and read what was recorded, because the material needed for that was never written down anywhere and cannot be reconstructed from what they hold.

Whether any given connection actually has this property depends entirely on which combination of algorithms the two sides agreed on, which is what a cipher suite names. The current generation of the protocol narrowed the available combinations considerably, which is part of why fewer connections lack it than used to.

One more consequence follows, and it is the reason the property is worth having even on sites with nothing secret in them. Traffic that is worthless to an attacker today may be valuable later: an address, a name, a pattern of use that means nothing now and identifies somebody in five years. Deciding today that a conversation will never matter is a prediction, and this property removes the need to make it.

What it does not cover

Four things, and each is a different conversation.

• It does not protect the future

  Somebody holding your key can present themselves as you until the certificate is replaced and the old one is no longer trusted anywhere, which is what revocation exists for and why it is a considerably harder problem than it first looks.

• It does not protect what either endpoint keeps

  Traffic being unreadable in transit says nothing about the copy sitting in your database, in your logs, or in the visitor's browser. Most data loss is not interception at all, and this property addresses only interception.

• It does not survive a compromised endpoint at the time

  If the server was already under somebody else's control when the conversation happened, that somebody had the session keys as well, because the server itself needed them to hold the conversation.

• It does not make recording pointless

  Traffic patterns, timing, sizes, and the name requested through SNI remain visible to anybody in the path, which is why that name is worth thinking about as a separate question.

Why it took so long to become normal

The arrangement costs a little more work per connection than the simpler one it replaced, and for years that cost was weighed against a threat that seemed theoretical: who would store encrypted traffic for years on the chance of a future key compromise? The answer turned out to be anybody with storage, and the calculation changed.

Configurations written before that shift are still running. They are not broken and their sites work, which is precisely why nobody revisits them. That makes this one of the few security properties worth checking on a working system rather than only on a failing one.

What to do about it

Very little, and the fact that there is little to do is itself the point.

This is not a setting you enable. It follows from which algorithms your server is willing to use, so the practical action is to configure from a current source rather than from an article of unknown age, and to check what your host actually agrees to against what its configuration file appears to say. The distinction matters because the effective list combines the software's defaults with your own settings.

If you inherited a configuration that predates the current protocol generation, that check is worth doing once, deliberately, rather than assuming either outcome. It takes a minute and either confirms something comforting or finds something that has been quietly true for years.

FAQ