Forward Secrecy Checker

Check Perfect Forward Secrecy support

ECDHE

DHE

Cipher Suite

About Forward Secrecy Checker

Perfect Forward Secrecy (PFS) ensures that a compromised private key cannot be used to decrypt past sessions. Our Forward Secrecy Checker tests whether a server supports ephemeral key exchange mechanisms like ECDHE and DHE, which generate unique session keys for each connection. Servers without PFS are vulnerable to retroactive decryption if their private key is ever exposed.

How to Use

1Enter the domain name you want to test for PFS support.
2Click "Check" to connect and analyze the server's cipher suite configuration.
3Review the ECDHE and DHE support indicators and the negotiated cipher suite.

Use Cases

•Verify PFS is enabled on production web servers and APIs
•Audit third-party services and CDN providers for PFS compliance
•Ensure compliance with security standards requiring PFS support
•Compare cipher suite preferences across different server configurations

Frequently Asked Questions

PFS generates a unique session key for each connection using ephemeral key exchange. If the server's private key is later compromised, past sessions cannot be decrypted because the session key is not derived from the private key.

ECDHE uses elliptic curve cryptography for key exchange, which is faster and more secure than DHE (Diffie-Hellman Ephemeral). ECDHE is preferred and widely supported in modern TLS configurations.

Restrict your cipher list to ephemeral key exchange suites, which is what provides forward secrecy. On Nginx a reasonable TLS 1.2 list is ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM, and on TLS 1.3 forward secrecy is mandatory so there is nothing to configure. For DHE suites you also need strong Diffie-Hellman parameters, generated with openssl dhparam, because a small or shared group is a separate vulnerability that has nothing to do with the cipher choice.

Yes, unconditionally. The protocol only permits ephemeral key exchange, so there is no suite without it and no configuration that removes it. That is one of the strongest arguments for enabling 1.3 — it closes the forward-secrecy gap structurally rather than by asking operators to configure their cipher lists correctly, which is where 1.2 deployments go wrong.

Traffic recorded today against a key compromised later. With ephemeral key exchange each session derives keys that cannot be recovered from the long-term private key, so an attacker who obtains your key years from now still cannot read traffic they captured now. Without it, every recorded session is decryptable the moment the key leaks. That is why it matters most for traffic with a long confidentiality lifetime.

No, and the distinction is about key lifetime rather than key strength. A 4096-bit RSA key is unbreakable by any foreseeable means, but if it is ever compromised — now or in ten years — every session it negotiated can be decrypted. Ephemeral keys discard the session secrets after use, so a later compromise reveals nothing about past traffic. Strength protects the key; secrecy protects the record.

Prefer suites with ECDHE or DHE in the name and remove static RSA and plain DH from your cipher list. In practice that means moving to TLS 1.3 where this is automatic, or on 1.2 narrowing to ECDHE suites with AES-GCM or ChaCha20. Then re-run this check and confirm the negotiated suite has changed, since the connection is what is being reported here.

No — it reports what this one handshake negotiated, which is the suite your visitors actually get. A server may also accept static RSA suites that this connection never chose, and an attacker with a downgrade path could try to force one. The cipher-order page on this site offers suites individually and reports which the server accepts, which answers the wider question.

How Secrecy Is Determined

Forward secrecy is a property of the key exchange, not of the certificate. This page completes a real handshake and inspects the negotiated suite to decide it.

1Check the protocol version first. On TLS 1.3 forward secrecy is unconditional — the protocol only defines ephemeral key exchange, so the answer is yes regardless of the suite name, and the page says exactly that.
2Otherwise inspect the suite name for ECDHE or DHE, which denote ephemeral key exchange. Both are reported by name, so you can see which mechanism provided the secrecy rather than just receiving a verdict.
3Report absence plainly, naming the suite that lacks it. Static RSA or plain DH key exchange means recorded traffic can be decrypted later if the long-term key is ever compromised, and the specific suite is what you need to remove.

A connection-level answer, like everything measured here: it describes what this handshake negotiated, not which suites the server would accept from a client offering something else. Pair it with the cipher-order page, which offers suites individually.

Tips & Best Practices

•Enable forward secrecy with ECDHE or DHE key exchange
•Prioritize forward secrecy cipher suites in server configuration
•Test forward secrecy support from different client configurations
•Monitor forward secrecy status across your infrastructure

Technical Details

Protocol: Forward Secrecy (Perfect Forward Secrecy) support
Key Exchange: ECDHE and DHE key exchange analysis
Security: Forward secrecy security benefits and implementation
Output: Forward secrecy support status with recommendations