🧩 09-03: Cipher Suites¶

📌 What a Cipher Suite Is¶

A cipher suite is a named bundle of cryptographic algorithms that a TLS connection agrees to use together — one algorithm for exchanging keys, one for authenticating the server (and optionally the client), one for encrypting the actual data, and one for checking data integrity. Rather than negotiating each of these four choices independently, TLS negotiates them as a single, pre-defined package, identified by one long, structured name.

💡 Think of a cipher suite name as a recipe card that lists four ingredients in a fixed order. Once you know how to read the card, any cipher suite name — no matter how unfamiliar — tells you exactly what cryptographic building blocks are in play.

🔬 Breaking Down a Cipher Suite Name¶

Take the example name:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

This single string encodes four separate decisions:

Component	Value in this example	What it specifies
Key Exchange	`ECDHE`	How the client and server derive a shared secret
Authentication	`RSA`	How the server (and optionally client) proves its identity
Bulk Cipher	`AES_128_GCM`	How the actual application data is encrypted
Hash/MAC	`SHA256`	How integrity is checked / how keys are further derived

Key Exchange: `ECDHE`¶

This tells you how the pre-master secret gets established. ECDHE stands for Elliptic Curve Diffie-Hellman Ephemeral — a variant of Diffie-Hellman key exchange (see 07-05: Diffie-Hellman Key Exchange) that uses elliptic curve math and generates a fresh key pair for every single session (that's what "ephemeral" means). This ephemeral property is exactly what provides forward secrecy: because the key exchange value is thrown away after the session ends and never derived from a long-term secret, recording today's traffic and stealing the server's private key next year still wouldn't let an attacker decrypt it.

Other key exchange values you might see: plain DHE (Diffie-Hellman Ephemeral, without elliptic curves — mathematically related but less efficient), or, in older/weaker suites, plain RSA used directly as the key exchange method (see below — this is the weak, non-forward-secret case).

Authentication: `RSA`¶

This tells you what kind of key/certificate the server uses to prove its identity during the handshake — in this case, an RSA keypair, verified via the server's certificate (see 07-08: Digital Certificates & PKI for how certificate-based authentication works). Other common values here are ECDSA (elliptic-curve-based signatures) or PSK (pre-shared key, used in some non-certificate scenarios).

💡 Notice that key exchange and authentication are two different jobs, even though they can both involve similar-sounding math. Key exchange establishes a shared secret; authentication proves who you established that secret with. A cipher suite can (and often does) use different algorithms for each — e.g., ECDHE for exchange and RSA for authentication in the same suite name.

Bulk Cipher: `AES_128_GCM`¶

Once the handshake produces session keys, this is the algorithm actually used to encrypt the application data flowing between client and server for the rest of the connection. AES_128_GCM means AES with a 128-bit key, running in GCM (Galois/Counter Mode) — a mode that provides both encryption and built-in integrity/authentication in one operation (an "AEAD" cipher — authenticated encryption with associated data). For the full explanation of AES and what "mode" means, see 07-03: AES & Block Cipher Modes.

Hash/MAC: `SHA256`¶

This specifies the hash function used for integrity purposes — historically for computing a separate MAC over each record, though in modern AEAD ciphers like GCM the integrity check is often built into the cipher mode itself, and the named hash is instead used within the handshake's key-derivation process (e.g., deriving the master secret and session keys, and computing the Finished message check described in 09-02: The TLS Handshake).

🤝 How Client and Server Negotiate a Cipher Suite¶

This negotiation happens right at the start of the handshake (see 09-02: The TLS Handshake for the full sequence):

The client's ClientHello includes a list of cipher suites it supports, ordered by preference.
The server compares that list against the cipher suites it supports, and picks one — typically the first mutually-supported suite in the client's preferred order, or according to the server's own preference policy.
The server announces the chosen suite in its ServerHello.

From that point forward, both sides know exactly which four algorithms will govern the rest of the connection.

💡 This negotiation step is also exactly where downgrade attacks target TLS: if an attacker can interfere with this exchange (for example, by manipulating early handshake messages before encryption is active), they may be able to trick both sides into agreeing on a weaker cipher suite than either would have chosen on their own. See 09-05: Common TLS Attacks for how this plays out in practice.

⚠️ Components Now Considered Weak or Deprecated¶

Not all values that can theoretically appear in a cipher suite name are still considered safe. A modern, secure configuration actively avoids:

Weak Component	Why It's Deprecated
RC4 (bulk cipher)	A stream cipher with statistical biases in its output that can be exploited to recover plaintext given enough captured traffic
SHA-1 (hash/MAC)	Cryptographically weakened — practical collision attacks have been demonstrated, undermining the security guarantees the hash was supposed to provide
Static RSA key exchange (key exchange method, i.e., `RSA` used for exchange rather than just authentication)	Provides no forward secrecy — the pre-master secret is encrypted directly with the server's long-term public key, so if that private key is ever compromised, all past traffic ever encrypted with it becomes retroactively decryptable
Export-grade ciphers (historical, artificially weakened key lengths)	Deliberately weakened for old export regulations; trivially breakable by modern computing power, and their mere presence in a server's supported list has enabled specific downgrade attacks
CBC-mode ciphers combined with certain padding schemes	Some CBC-mode configurations in TLS 1.0/1.1 were vulnerable to padding-oracle-style attacks (conceptually related to the BEAST issue discussed in 09-05: Common TLS Attacks)

💡 Notice that "static RSA key exchange" and "RSA authentication" are not the same weakness. Using RSA to authenticate the server (verify its certificate/signature) is still perfectly fine and widely used today. The problem is specifically using RSA encryption as the key exchange mechanism itself — that's the version that sacrifices forward secrecy. This is exactly why reading a cipher suite name component-by-component matters: the same algorithm name can appear in a safe role and an unsafe role depending on which "slot" it's filling.

✅ What a Modern, Recommended Cipher Suite Looks Like¶

A cipher suite considered strong today generally has this shape:

Key exchange: ECDHE (or DHE) — ephemeral, forward-secret
Authentication: RSA or ECDSA — backed by a valid certificate chain
Bulk cipher: an AEAD cipher such as AES_128_GCM, AES_256_GCM, or CHACHA20_POLY1305
Hash: SHA256 or stronger — never SHA-1 or MD5

TLS 1.3 goes a step further and simplifies this whole discussion: it only defines a small, curated set of cipher suites, all of which use ephemeral key exchange and modern AEAD ciphers — there is no way to accidentally negotiate a weak combination, because the weak combinations were never included in the protocol to begin with (see 09-01: TLS History & Versions).

📌 Key Takeaways¶

A cipher suite name encodes four algorithm choices in order: key exchange, authentication, bulk cipher, hash/MAC.
Key exchange (e.g., ECDHE) establishes the shared secret; authentication (e.g., RSA, ECDSA) proves identity — they're separate jobs even when the algorithm names look similar.
Ephemeral key exchange methods (ECDHE, DHE) provide forward secrecy; static RSA key exchange does not.
The bulk cipher (e.g., AES_128_GCM) protects the actual application data after the handshake completes.
Client and server negotiate a cipher suite during the handshake: the client offers a preference-ordered list, the server picks one it supports.
Weak/deprecated components to watch for: RC4, SHA-1, static RSA key exchange, and export-grade ciphers.
TLS 1.3 sidesteps most of this danger by only supporting a small set of modern, forward-secret cipher suites from the start.
Understanding cipher suite names is directly useful for reading server configuration audits and vulnerability scan reports, where weak suites are flagged by exactly these component names.