tls.cipher.no_pfs
No Perfect Forward Secrecy
What we check
We check whether the negotiated cipher suite provides forward secrecy (also called perfect forward secrecy, PFS). Forward secrecy means each session uses a unique ephemeral key, so compromising the server's long-term private key does not retroactively decrypt past sessions. Cipher suites using ECDHE or DHE key exchange provide forward secrecy; plain RSA key exchange does not.
What this finding means
The server negotiated a cipher suite without forward secrecy — typically a plain RSA key exchange (e.g., TLS_RSA_WITH_AES_256_CBC_SHA). If the server's private key is ever compromised (stolen, leaked, or compelled by a legal order), an attacker who recorded past encrypted sessions can decrypt all of them.
Why it matters
- Retroactive decryption. Without forward secrecy, every past session encrypted with the server's key is vulnerable if that key leaks — even years later.
- Best practice since 2015. RFC 7525 (BCP 195) recommends forward secrecy for all TLS deployments. TLS 1.3 mandates it — only cipher suites with ephemeral key exchange exist in TLS 1.3.
- Passive surveillance defense. Forward secrecy protects against passive recording and later bulk decryption — a documented real-world threat.
How to fix
Prefer ECDHE cipher suites. For Postfix:
# /etc/postfix/main.cf smtpd_tls_ciphers = medium tls_medium_cipherlist = ECDHE+AESGCM:DHE+AESGCM:ECDHE+AES:DHE+AES:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DESEnable TLS 1.3 — it mandates forward secrecy by design. No TLS 1.3 cipher suite uses plain RSA key exchange.
Verify:
openssl s_client -starttls smtp -connect mail.example.com:25 \ -servername mail.example.com 2>/dev/null | grep -E "Cipher|Protocol" # Look for ECDHE or DHE in the cipher name
How it's graded
No forward secrecy carries a 15-point deduction in the TLS category. See Grading Methodology for the full scoring model.
Evidence example
Negotiated cipher: TLS_RSA_WITH_AES_256_CBC_SHA256
Key exchange: RSA (no forward secrecy)