What are Perfect Forward Secrecy (PFS) and ECDHE?
Short answer
Perfect Forward Secrecy (PFS) is the property that, because an ephemeral key exchange is performed in every TLS connection, previously recorded traffic cannot be decrypted even if the server's private key is compromised later. The ephemeral key exchange is performed with Diffie-Hellman: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) or DHE; static RSA key exchange does not provide PFS, whereas in TLS 1.3 every connection has PFS. In TR7, in the Cipher Algorithms field of the TLS Security Profile, the General, Strict Secure, Strict Legacy Compatible and Strict Hardware Accelerated sets allow only cipher suites that use ECDHE or DHE; the Curve/ECDHE field determines the curves to be used in ECDHE.
Where It Is Used in TR7
| Where | Field / label | What for |
|---|---|---|
| Certificates & PKI → TLS Security Profiles | Cipher Algorithms: General, Strict Secure, Strict Legacy Compatible, Strict Hardware Accelerated | Allowing only suites with PFS: General lists only ECDHE and DHE suites, and the Strict sets exclude static RSA key exchange (kRSA) |
| TLS Security Profiles | Curve/ECDHE (off by default; when turned on, curves are selected from the list, e.g. X25519 (TLS v1.3 only), secp256r1, secp384r1) | The curves to be offered in ECDHE and their preference order; while the field is off, the default curves are used |
| TLS Security Profiles → Frontend-only Settings | Post-Quantum Key Exchange | Offering the hybrid group that combines ECDHE with ML-KEM in TLS 1.3 |
| Load Balancer → Conditions (Policy Match) | SSL Cipher | A decision based on the cipher suite the client negotiated (e.g. a suite without ECDHE) |
How Does It Work?
- In every connection, the client and the server each generate an ephemeral key pair for that connection only and exchange the public parts.
- The two sides derive a shared secret from these values; the session keys are obtained from this secret.
- The server's private key belonging to the certificate is used only to prove the server's identity by signing this exchange; it does not participate in deriving the session key.
- Because the ephemeral keys are discarded when the connection ends, recorded traffic cannot be decrypted with a private key that is compromised later.
For TLS 1.2, the current recommendations are to use only suites that provide forward secrecy (RFC 9325).
Common Misconceptions
- "A strong RSA key provides PFS." PFS comes from the key exchange method, not from the key length; with static RSA key exchange it is not provided, however long the key is.
- "PFS causes a serious performance loss." ECDHE has a low cost on current hardware and is already used in every connection in TLS 1.3.
- "If the Curve/ECDHE field is empty, ECDHE is not used." Even while the field is off, ECDHE is performed with the default curves; the field determines only the curve list and its order.
How it is done in the documentation
