Reading A Cipher Suite Name

Open any TLS configuration file and you'll see lines like this:

ECDHE-RSA-AES256-GCM-SHA384
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
ECDHE-ECDSA-AES128-GCM-SHA256

They look like license plates. They're actually sentences that describe every important property of the connection — how keys are exchanged, how the server is authenticated, how bytes are encrypted, and how things are hashed. Once you know how to read them, you can look at any TLS config and instantly tell whether it's safe or sketchy.

Anatomy Of A TLS 1.2 Cipher Suite

Let's take apart ECDHE-RSA-AES256-GCM-SHA384. It has five parts:

• ECDHE — the key exchange algorithm (how the shared secret is agreed);
• RSA — the authentication algorithm (what kind of key the server's certificate uses);
• AES256 — the bulk encryption algorithm (what scrambles the data);
• GCM — the encryption mode (how the cipher is applied);
• SHA384 — the hash function (used for the MAC and key derivation).

Five chunks, five jobs. Let's go through each.

Part 1 — ECDHE (Key Exchange)

ECDHE stands for Elliptic Curve Diffie-Hellman Ephemeral. Let's break that down:

• Elliptic Curve — uses elliptic curve math, which is fast and uses small keys (~32 bytes vs ~256 bytes for RSA);
• Diffie-Hellman — the algorithm where two parties derive a shared secret without ever sending it;
• Ephemeral — fresh keys for every connection. This is what gives Perfect Forward Secrecy — even if the server's long-term private key leaks tomorrow, today's traffic stays safe.

You might also see:

• DHE — non-elliptic Diffie-Hellman Ephemeral. Same idea, slower and bigger keys;
• RSA (as key exchange) — uses RSA encryption to share a key. No PFS. Removed in TLS 1.3;
• ECDH (no E) — static ECDH. Also no PFS. Almost never used.

If a cipher suite name doesn't end in E somewhere, it's probably missing PFS. Skip it.

Part 2 — RSA Or ECDSA (Authentication)

This is the algorithm used to sign the key exchange — proving to the client that it's really talking to the server whose certificate it just verified.

• RSA — the server's certificate uses an RSA key. Widely supported, larger signatures (~256 bytes);
• ECDSA — elliptic curve digital signature algorithm. Smaller signatures (~64 bytes), faster verification. Increasingly preferred;
• Ed25519 (in TLS 1.3) — newer EC signature scheme. Faster and more secure than ECDSA.

In TLS 1.2 cipher suite names, this part is mandatory. In TLS 1.3, it's negotiated separately and dropped from the cipher suite name entirely.

Part 3 — AES128 Or AES256 (Bulk Encryption)

This is what actually encrypts every byte of HTTP data. The number is the key length:

• AES128 — 128-bit key. Plenty secure, slightly faster;
• AES256 — 256-bit key. Overkill for most uses, slightly slower, but considered "post-quantum-aware" since quantum attacks against AES are halved (256-bit AES still gives 128 bits of post-quantum security);
• CHACHA20 (instead of AES) — a stream cipher designed for software speed. Used heavily on mobile devices that don't have AES hardware acceleration.

All three are safe. Mainstream advice in 2026: use AES-GCM with hardware support, fall back to ChaCha20-Poly1305 for clients without it. Most servers list both.

Part 4 — GCM Or CBC (Mode)

This is the most important chunk to check.

• GCM — Galois/Counter Mode. An AEAD mode — encrypts and authenticates in one operation. No padding oracle attacks possible. Modern, fast, safe;
• CBC — Cipher Block Chaining. Old mode that pairs encryption with a separate MAC step. The order of those steps matters and getting it wrong caused real attacks: BEAST (2011), Lucky 13 (2013), POODLE (2014). Avoid CBC in 2026. TLS 1.3 banned it entirely.
• CCM — another AEAD mode, less common. Safe but rare.

When auditing a TLS config, the rule is simple: if you see CBC, change it to GCM.

Part 5 — SHA256 Or SHA384 (Hash)

This is the hash function used internally for the key derivation, the MAC, and the Finished message.

• SHA256 — 256-bit output. Fine for everything;
• SHA384 — 384-bit output. Used when paired with AES256 for "matching strength";
• SHA1 or MD5 — broken. Removed from modern configs.

The pairing tends to be AES128-GCM-SHA256 or AES256-GCM-SHA384. Don't think too hard about it.

TLS 1.3 — Shorter Names, Same Idea

TLS 1.3 dropped key exchange and authentication from the cipher suite name because they're now negotiated separately. The five suites you'll see:

• TLS_AES_128_GCM_SHA256;
• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_128_CCM_SHA256;
• TLS_AES_128_CCM_8_SHA256.

In practice, the first three are what every server enables and what every client uses. The CCM ones are mostly for IoT.

The Audit Cheat Sheet

When you look at a cipher suite list in a config file, scan for:

• Anything with RSA (not RSA as auth, but RSA as key exchange — usually at the very start) → flag it, no PFS;
• Anything with CBC → flag it, modern attacks;
• Anything with MD5, SHA1, RC4, 3DES, EXPORT, or NULL → flag it, ancient junk;
• Anything starting with TLS_ (TLS 1.3 names) or ECDHE- + GCM → safe.

Next chapter, we go deeper into the magic word from this one — ephemeral — and the security property it provides: Perfect Forward Secrecy.