Anatomy of a TLS Cipher Suite

What a TLS cipher suite actually names, how to read a suite like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 piece by piece, and how the same two-byte code point shows up under three different naming conventions.

Origins: why a suite exists at all

Early protocol designs hard-wired their cryptography. Changing an algorithm meant changing the protocol, which meant a flag day, which meant it never happened — and the algorithm was still in the field long after it was broken.

SSL introduced negotiation instead: a client offers the combinations it supports, the server picks one, and both proceed. The cipher suite is that combination named as a single unit, with an assigned code point so it can be offered in a list.

That decision bought thirty years of algorithm agility and created its own failure mode, which the record documents thoroughly:

Downgrade attacks. If a weak option is still offered, an attacker who can influence the negotiation can force it. and exploited export-grade suites that remained enabled for a decade after the legal reason for them ended.
Combinatorial explosion. TLS 1.2 defines hundreds of registered suites. Every additional option is another interaction to reason about, and the weakest accepted option sets the actual security.
Configuration as the real risk. The dangerous cipher suite is almost never the one an attacker breaks mathematically; it is the one left enabled by a template copied from somewhere else.

TLS 1.3's answer was subtraction. Suites no longer include key exchange or authentication at all — those are negotiated separately — so a suite names only the symmetric cipher and the hash. Five are defined. A TLS 1.3 suite name is shorter because the protocol removed the choices that made the long names necessary.

What a cipher suite is

A TLS cipher suite is a named bundle of cryptographic choices that a client and server agree on during the handshake. A single name like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 packs several independent decisions into one identifier: how the two sides agree on a shared secret, how the server proves who it is, which algorithm encrypts the application data, and how that data is protected from tampering.

Every registered suite also has a two-byte code point, assigned by (the Internet Assigned Numbers Authority). The name above is 0xC02F on the wire. The handshake never sends the text name; it sends the two bytes. The names exist for humans, and there is more than one naming convention, which is a frequent source of confusion.

The jobs a suite describes

For TLS 1.2 and earlier, a suite names up to five things:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    |     |        |   |   |   |
    |     |        |   |   |   +-- MAC / PRF hash: SHA-256
    |     |        |   |   +------ mode of operation: GCM (an AEAD mode)
    |     |        |   +---------- cipher key size: 128-bit
    |     |        +-------------- bulk cipher: AES
    |     +----------------------- authentication: RSA
    +----------------------------- key exchange: ECDHE

Key exchange is how the two sides establish a shared secret. ECDHE is ephemeral elliptic-curve , which gives forward secrecy. Other values you will see are DHE (ephemeral finite-field Diffie-Hellman), RSA (static key transport, no forward secrecy), and PSK (a pre-shared key).

Authentication is how the server (and sometimes the client) proves its identity, almost always with the private key behind its certificate. RSA and ECDSA are the common values. When a suite uses static RSA for key exchange, the same RSA key does both jobs, so the name lists RSA only once.

Bulk cipher and key size is the symmetric algorithm that encrypts the actual traffic once the handshake is done. AES_128 and AES_256 dominate; CHACHA20 is the common alternative on devices without hardware.

Mode turns the block cipher into something that can encrypt a stream of records. GCM, CCM, and CHACHA20_POLY1305 are modes that handle integrity themselves. CBC is the older mode that needs a separate MAC.

MAC or hash is the last token - MAC being the message authentication code and PRF the pseudorandom function. In a suite it is the (hash-based message authentication code) hash that authenticates each record. In an AEAD suite the cipher already provides integrity, so the trailing hash instead names the PRF that the handshake uses to derive keys (SHA256 or SHA384).

Reading it the other way

Once you know the grammar, you can read any TLS 1.2 suite backwards from a single glance. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 is ephemeral finite-field Diffie-Hellman for key exchange, RSA for authentication, AES with a 256-bit key in mode, and -384 as the handshake PRF. Because GCM is AEAD, there is no separate MAC.

TLS_RSA_WITH_AES_128_CBC_SHA is the cautionary opposite: static RSA key transport with no forward secrecy, AES-128 in CBC mode, and an HMAC-SHA1 MAC. Every part of that is legacy, which is why IANA now marks it discouraged.

One suite, three names

The same 0xC02F appears under three conventions:

IANA:    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
OpenSSL: ECDHE-RSA-AES128-GCM-SHA256
GnuTLS:  TLS_ECDHE_RSA_AES_128_GCM_SHA256

The IANA name is the registry standard. OpenSSL uses hyphens, drops the WITH, and writes AES128 as one token, which is why an OpenSSL config and a packet capture can look like they disagree when they name the same suite. The decoder accepts all three forms, plus the raw code point, and shows you the others.

Choosing, and what actually matters

The order of importance in practice is the reverse of how much attention each part gets:

Which protocol versions are enabled. TLS 1.0 and 1.1 off, 1.2 as the floor, 1.3 preferred. This single setting decides more than any suite list.
AEAD only. Authenticated encryption with associated data — the CBC-based constructions carry the padding-oracle history and gain nothing.
Forward secrecy. Ephemeral key exchange, so a compromised long-term key does not decrypt yesterday's captured traffic. Mandatory in TLS 1.3, optional and frequently unset in 1.2.
Order and preference. Whether the server enforces its own preference matters when clients offer weak options.
The specific suite — which, if the four above are right, is nearly a detail.

Hardware shapes the honest default. AES with dedicated instructions is faster than ChaCha20 on modern server processors; ChaCha20-Poly1305 is faster where those instructions are absent, which is much of the mobile and embedded world. Offering both and letting the client's preference decide is the sound configuration, not a hedge.

What is coming is the post-quantum transition, and it lands on key exchange rather than on the symmetric cipher: hybrid schemes that combine a classical curve with a lattice-based exchange are already deployed by browsers and large networks. Symmetric algorithms and hashes are far less affected, so a suite list will change less than the key-exchange configuration around it.

Where the choice actually gets made

TLS libraries — OpenSSL, BoringSSL, GnuTLS, NSS, rustls — each with its own default list and its own naming. The same suite has an IANA name, an OpenSSL name and a GnuTLS name, which is why a configuration copied between them so often fails to mean what it did.
Servers and proxies, which express the choice in their own syntax and frequently ship a list that outlives its correctness.
Platform policies — operating systems and managed runtimes that override the application's list entirely, which is where "the code says X but the wire says Y" comes from.
Compliance regimes that mandate particular suites, sometimes lagging current advice, and which are the reason an otherwise indefensible option is still enabled somewhere.

The practical rule: configure the version floor and the AEAD requirement, take the library's modern default for the rest, and test what the wire actually negotiates rather than what the configuration file appears to say.

Decoding is not endorsing

Reading a suite tells you what it would do, not whether you should use it. A name can be perfectly well formed and still describe RC4, key exchange, or export-grade keys. The decoder pairs the structural breakdown with a security read-out and the independent IANA recommendation, so a healthy-looking name with a fatal flaw does not slip past. The companion articles cover what makes a suite modern: AEAD over CBC, and forward secrecy in the key exchange.

To see where each piece of a suite actually lands on the wire, The Illustrated TLS 1.2 Connection and The Illustrated TLS 1.3 Connection annotate real handshakes byte by byte — one for the long bundled names, one for the short modern ones.