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.

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.

What is the TLS Cipher Suite Reference?

Searchable TLS cipher suite reference mapping each IANA name to its OpenSSL name, key exchange, authentication, cipher and MAC, with a security rating reflecting modern Mozilla and NIST guidance. Bundled offline. It runs free in your browser on Gera Tools, with nothing uploaded.

TLS Cipher Suite Reference

Name: TLS Cipher Suite Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click 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.

Why IANA names and OpenSSL names differ

The IANA registry is the authoritative source of truth, and its names follow a systematic TLS_<KeyExchange>_<Auth>_WITH_<Cipher>_<Hash> pattern. OpenSSL uses its own shorter naming scheme that predates the IANA format. The same cipher suite appears as two different strings depending on context: IANA names appear in RFC documents and protocol analyzers like Wireshark; OpenSSL names appear in server config files. This reference shows both so you can map between them without guesswork.

For example:

IANA: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
OpenSSL: ECDHE-RSA-AES256-GCM-SHA384

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.

Recommended allowlist for modern servers

A solid configuration supports TLS 1.3 and a limited subset of TLS 1.2:

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

This set maintains compatibility with nearly all modern clients while dropping every weak and insecure suite.

What to remove and why

Pattern to remove	Reason
RC4	Biased keystream; practically attackable; prohibited by RFC 7465
3DES / DES-CBC3	Sweet32 birthday attack on connections with large data volumes
NULL	No encryption — data is sent in plaintext
Anonymous (`aNULL`)	No server authentication — trivial man-in-the-middle
Static RSA (`kRSA`)	No forward secrecy; server key compromise decrypts old sessions
Bare `AES-CBC` suites	Padding-oracle vulnerability (POODLE, BEAST, Lucky13)

Use the protocol filter in this reference to confirm a suite is valid for the TLS version you are configuring — TLS 1.3 will never negotiate a TLS 1.2 CBC suite regardless of what your config says.

AES-GCM vs ChaCha20-Poly1305

Both are modern AEAD ciphers and both receive a “secure” rating. The practical difference is hardware: AES-GCM is fastest on CPUs with AES-NI instructions (virtually all server hardware and recent laptops). ChaCha20-Poly1305 is faster and constant-time on hardware without AES-NI, such as lower-end mobile devices. Offering both lets TLS negotiate the best fit per client.