Why do TLS 1.3 cipher suite names look different?

TLS 1.3 decoupled key exchange and authentication from the cipher suite, so a name like TLS_AES_256_GCM_SHA384 only names the AEAD cipher and hash. Key exchange is always ephemeral (forward-secret) and the certificate's key type provides authentication.

What makes a cipher suite weak or insecure?

Static RSA key exchange removes forward secrecy; CBC modes are exposed to padding-oracle and Lucky13 timing attacks; and 3DES (Sweet32), RC4 and NULL ciphers are broken outright. Prefer AEAD modes (GCM or ChaCha20-Poly1305) with ECDHE or DHE.

What is forward secrecy and which suites provide it?

Forward secrecy means compromising the server's long-term key does not decrypt past sessions, because each session uses an ephemeral key. Any suite using ECDHE or DHE provides it; all TLS 1.3 suites provide it by design. Static RSA suites do not.

Should I prefer AES-GCM or ChaCha20-Poly1305?

Both are strong AEAD ciphers. AES-GCM is fastest on hardware with AES-NI acceleration, while ChaCha20-Poly1305 is faster and constant-time on devices without it, such as many phones. Offering both lets clients negotiate the best fit.

Are the OpenSSL names the same as the IANA names?

No. OpenSSL uses its own shorter names — for example the IANA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is ECDHE-RSA-AES256-GCM-SHA384 in OpenSSL. This tool shows both so you can map between config files and packet captures.

TLS Cipher Suite Reference

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

A TLS cipher suite is the bundle of algorithms a client and server agree on for a connection: how they exchange keys, how they authenticate, which symmetric cipher protects the data and how integrity is checked. Picking strong suites — and disabling broken ones — is one of the highest-leverage steps in securing HTTPS. This reference maps each IANA suite to its OpenSSL name and rates it against modern guidance.

How it works

In TLS 1.2 a suite name spells out all four parts, for example TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: ECDHE key exchange, RSA authentication, AES-256-GCM cipher, SHA384 for the PRF. TLS 1.3 simplified this — suites such as TLS_AES_128_GCM_SHA256 name only the AEAD cipher and hash, because key exchange is always ephemeral and authentication comes from the certificate.

The rating column follows current best practice: AEAD ciphers (GCM, ChaCha20-Poly1305) with forward secrecy (ECDHE/DHE) are recommended; CBC and static-RSA suites are weak; and 3DES, RC4 and NULL are insecure and should be removed.

Tips and examples

A solid modern allowlist looks roughly like this:

TLS 1.3: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256,
         TLS_CHACHA20_POLY1305_SHA256
TLS 1.2: ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384,
         ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-AES128-GCM-SHA256

Anything containing RC4, 3DES/DES-CBC3, NULL, or a bare AES...-SHA (static RSA + CBC) should be disabled. Use the protocol filter to confirm a suite is even valid for the version you are configuring — TLS 1.3 will never negotiate a TLS 1.2 CBC suite.