A TLS cipher suite name packs four decisions into one string: how keys are exchanged, how the server is authenticated, which bulk cipher encrypts the data, and which hash provides integrity. This tool unpacks any suite and tells you whether it still meets modern guidance or should be retired.
Reading a cipher suite name
Take the suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 — each segment communicates a specific algorithm choice:
| Segment | Meaning |
|---|---|
ECDHE | Key exchange: Ephemeral Elliptic Curve Diffie-Hellman (provides forward secrecy) |
RSA | Authentication: the server’s certificate uses an RSA key |
AES_128_GCM | Bulk cipher: AES in Galois/Counter Mode, 128-bit key (an AEAD cipher) |
SHA256 | PRF/hash for key derivation and integrity |
TLS 1.3 suites look different. TLS_AES_256_GCM_SHA384 names only the AEAD cipher and hash — key exchange is always ephemeral in TLS 1.3, and the certificate handles authentication, so those parts are omitted from the suite name.
How it works
You can enter either the IANA name or the two-byte hex code (for example 0xC02F). The tool resolves one form to the other using a bundled slice of the IANA registry, then parses the components and applies BSI/NIST-aligned rules to produce an overall rating with specific reasons.
The rating logic:
- Insecure: RC4 (biased keystream, attackable), MD5 (collisions), NULL cipher (no encryption), anonymous key exchange (no authentication), export-grade (weak keys)
- Weak: 3DES (Sweet32 birthday attack on long sessions), CBC mode in TLS 1.2 (padding-oracle exposure), static RSA key exchange (no forward secrecy)
- Secure: Modern AEAD ciphers (GCM, ChaCha20-Poly1305) with ephemeral key exchange
Worked examples
Decode 0x0005:
- Resolves to
TLS_RSA_WITH_RC4_128_SHA - Insecure — RC4 is prohibited (RFC 7465); static RSA has no forward secrecy
Decode 0xC02B:
- Resolves to
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - Secure — ECDHE provides forward secrecy; AES-GCM is AEAD; ECDSA is a modern authentication scheme
Decode 0x1303:
- Resolves to
TLS_CHACHA20_POLY1305_SHA256 - Secure — a TLS 1.3 suite; ChaCha20-Poly1305 is a fast, constant-time AEAD cipher preferred on mobile hardware without AES acceleration
What to do with a weak or insecure result
If a suite your server advertises is flagged weak or insecure:
- Edit your server’s cipher list (Nginx:
ssl_ciphers; Apache:SSLCipherSuite) to remove the offending suite. - Test with a tool like SSL Labs before and after to confirm it is no longer offered.
- For maximum future-proofing, configure TLS 1.3 as the minimum and let TLS 1.2 run only the secure AEAD+ECDHE suites as a fallback.
Forward secrecy: why it matters for old traffic
Forward secrecy is a property where past sessions cannot be decrypted even if the server’s long-term private key is later compromised. Suites using static RSA key exchange do not have this: if an attacker records encrypted traffic today and obtains your private key years later, they can retroactively decrypt every recorded session. Ephemeral key exchange (ECDHE or DHE) generates a fresh session key each time, so historical recordings cannot be unlocked even with the server key. The decoder flags all non-forward-secret suites regardless of the bulk cipher strength, because this is an architectural weakness that no cipher strength can compensate for.
The bundled registry covers the suites you meet in real server configurations. Ratings reflect current deployment guidance aligned with NIST SP 800-52 and BSI TR-02102.