Analyze TLS cipher suites and security strength recommendations. Part of the DevTools Surf developer suite. Browse more tools in the Security / Crypto collection.
Use Cases
Audit a server's cipher suite configuration against current security recommendations before a compliance review.
Identify deprecated ciphers (RC4, DES, 3DES, MD5-based MACs) that should be disabled.
Verify that forward secrecy is enabled across all supported cipher suites.
Check TLS version support to confirm TLS 1.0/1.1 are disabled per PCI DSS 4.0 requirements.
Tips
Prioritize AEAD cipher suites (GCM, CCM, ChaCha20-Poly1305) — they provide authenticated encryption, making padding oracle attacks impossible.
Disable TLS 1.0 and 1.1 — both are deprecated by RFC 8996 (2021) and are required to be disabled for PCI DSS compliance.
Forward secrecy (PFS) cipher suites use ephemeral key exchange (ECDHE, DHE) — ensure these are prioritized over static RSA key exchange, which lacks forward secrecy.
Fun Facts
TLS 1.3, finalized in RFC 8446 (2018), removed support for cipher suites without forward secrecy and AEAD — making it the most secure TLS version by design. Adoption reached 60% of TLS connections by 2023.
The POODLE attack (2014) against SSL 3.0 and the BEAST attack (2011) against TLS 1.0 were the primary catalysts for deprecating these protocol versions — both exploited padding oracle vulnerabilities in CBC mode ciphers.
RC4, once the most widely used stream cipher in TLS, was formally prohibited in TLS by RFC 7465 (2015) after researchers demonstrated practical plaintext recovery attacks requiring only millions of connections.
FAQ
What cipher suites should I support in 2024?
TLS 1.3 suites only for new services: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. For TLS 1.2 backward compatibility: ECDHE+AESGCM and ECDHE+CHACHA20 suites with SHA256 or SHA384.
What is forward secrecy and why does it matter?
Forward secrecy uses ephemeral session keys that are discarded after the session. Even if the server's long-term private key is later compromised, recorded past sessions cannot be decrypted. This is achieved using ECDHE or DHE key exchange.
