TLS Cipher Suite Checker: Know What a Suite Name Actually Means
TLS cipher suite names are dense — TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 packs the key exchange method, authentication algorithm, symmetric cipher, and MAC/hash into one identifier. This tool is a searchable reference for decoding those names and understanding whether a given suite is safe to keep enabled, rather than a live scanner (which browser JavaScript cannot perform against an arbitrary remote server).
TLS 1.3 suite names drop the key exchange/auth portion entirely, since those are negotiated separately.
Reading a Cipher Suite Name
Take TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: ECDHE is the key exchange (elliptic-curve Diffie-Hellman, ephemeral — meaning forward secrecy), RSA is how the server authenticates itself, AES_128_GCM is the symmetric cipher and mode (128-bit AES in Galois/Counter Mode, an AEAD construction), and SHA256 is the hash used in the suite's PRF/handshake integrity. Each piece has security implications on its own.
Why Forward Secrecy Is the First Thing to Check
Suites built on ECDHE or DHE key exchange generate a fresh, temporary key for every session, so a future compromise of the server's long-term private key can't be used to decrypt previously recorded traffic. Suites using plain RSA key exchange (TLS_RSA_WITH_...) reuse the server's certificate key directly for key exchange, meaning all past sessions become decryptable the moment that key leaks — this is why this tool always marks static-RSA suites down.
AEAD vs. CBC Mode
Modern suites use AEAD ciphers (GCM, ChaCha20-Poly1305) that combine encryption and integrity checking in one operation with no known padding-oracle class of attacks. Older CBC-mode suites (AES256-SHA, etc.) require a separate MAC and have a long history of padding-oracle vulnerabilities (BEAST, Lucky 13) — they're not immediately broken, but AEAD suites are strictly preferable when available.
Suites That Should Simply Be Disabled
RC4-based suites are banned outright by RFC 7465 due to statistical biases in the keystream. 3DES suites are vulnerable to the SWEET32 birthday-bound attack on their 64-bit block size. Export-grade suites (RSA_EXPORT, 40-bit keys) exist only due to 1990s US export law and are trivially breakable today. Anonymous Diffie-Hellman suites provide no authentication at all, making them defenseless against a man-in-the-middle.
Practical Examples
Auditing a Server Config
You found `ECDHE-RSA-AES256-GCM-SHA384` in an nginx ssl_ciphers directive.
- 1.Search: ECDHE-RSA-AES256-GCM-SHA384
- 2.Result: Recommended — forward secrecy, AEAD cipher, no known weaknesses
Investigating a Scanner Warning
A vulnerability scan flagged `TLS_RSA_WITH_3DES_EDE_CBC_SHA` as enabled.
- 1.Search: 3DES
- 2.Result: Insecure — vulnerable to SWEET32, should be disabled
What's Included
- 25 common cipher suites spanning TLS 1.0 through TLS 1.3
- IANA and OpenSSL naming for each
- Key exchange, auth, cipher, and MAC breakdown
- Security rating: Recommended / Secure / Weak / Insecure
For Live Testing, Use
openssl s_client -connect host:443 -cipher SUITEnmap --script ssl-enum-ciphers -p 443 host- testssl.sh for a full automated report
- Qualys SSL Labs Server Test for a graded public report
Frequently Asked Questions
Does this tool test my actual server's TLS configuration?
No — browser JavaScript has no way to inspect what cipher suites a remote server offers or negotiates. This is a static reference table for looking up a cipher suite name you already have (from a server config, a scan report, or documentation) and understanding what it means.
How do I check what ciphers my server actually offers?
Use `openssl s_client -connect host:443 -cipher
Why do TLS 1.3 cipher suite names look different from TLS 1.2 ones?
TLS 1.3 simplified cipher suite negotiation — it decoupled the key exchange and authentication method (now negotiated separately via supported groups and signature algorithms) from the record-layer symmetric cipher, so a TLS 1.3 suite name only specifies the AEAD cipher and hash, like TLS_AES_256_GCM_SHA384.
What makes a cipher suite 'insecure' rather than just 'weak'?
This tool marks a suite insecure if it has a known practical attack (RC4 stream cipher biases, SWEET32 against 64-bit block ciphers like 3DES, FREAK against export-grade crypto) or provides no authentication at all (anonymous Diffie-Hellman). 'Weak' suites lack forward secrecy or use outdated primitives like SHA-1 MACs, but don't have a well-known practical break.
What is 'forward secrecy' and why does it matter for the rating?
Forward secrecy (provided by ephemeral key exchange — ECDHE or DHE) means that even if a server's long-term private key is later compromised, past recorded traffic can't be decrypted, because each session used a temporary key that's discarded afterward. Suites using static RSA key exchange lack this protection entirely.
Is my data sent anywhere?
No — this is a static local lookup table with no network requests.