Forward Secrecy for a VPN: What a Stolen Key Can Unlock

Record an encrypted tunnel today, steal the server's long-term private key next year, and try to decrypt the recording. Forward secrecy is the property that says the stolen key will not be enough on its own. It is a statement about recorded sessions and specific secrets, not a general promise that the tunnel was safe. Getting the scope right is what makes the term useful.

The question is about a recording, not the live session

The long-term key identifies the endpoint and signs the handshake. Session keys encrypt the actual traffic, and in a forward-secret design they are derived from fresh key-exchange material that both sides generate and later discard. An attacker holding only the long-term key cannot reconstruct those discarded values. An attacker holding live session state still can, which is why the guarantee is about the past rather than the present.

The claim is conditional: it holds only if the ephemeral secrets really were destroyed and the protocol is the one you think it is. A mixed deployment can satisfy it on one tunnel and fail on another.

One secret must not rebuild the others

Check the negotiated mode rather than the marketing page. The handshake output names the key exchange and the protocol version.

openssl s_client -connect vpn.example.com:443 -tls1_3 -brief
swanctl --list-sas

The s_client summary shows the TLS version and key-exchange group, and an ephemeral group is the visible sign of forward-secret key agreement. The swanctl listing shows IKE and CHILD associations with their rekey timers, so you can see whether the deployment renews keys on a schedule. A static RSA key exchange, or an old compatibility mode, loses the property regardless of the cipher name. Record the mode you observed rather than the one the vendor advertised.

Rekeying is not automatically forward secrecy

How often a tunnel rekeys is a separate question from how each key is derived. A design that regenerates keys from a long-term secret can rekey every minute and still fail the test, because a later compromise reconstructs all of them. Conversely, a protocol with infrequent rekeying can still be forward secret when each exchange is independent. Read the derivation, not the interval, and do not confuse a short reconnect timer with a cryptographic guarantee.

The same confusion appears with cipher names: a modern cipher says nothing about how its key arrived.

What remains visible after the guarantee

Forward secrecy protects the plaintext of recorded sessions from a future key compromise, and it does nothing about an attacker reading live traffic on a compromised endpoint. It does not remove destination addresses, timing or volume from the recording, and it does not constrain how long an operator keeps connection logs. Nor does it turn a compromised client into a trustworthy one, because the attacker already sits where content exists in the clear.

When a provider claims forward secrecy, ask which long-term secret is assumed stolen and which session secrets stay unavailable. If those two questions have crisp answers, the claim means something.