One Name, Several Algorithms
Securing a connection is not a single job — it is four, and no one algorithm does them all well. So TLS bundles a complete set into a named package called a cipher suite. When the TLS handshake begins, the client offers a list of suites it supports and the server picks one; that single choice locks in how the entire connection will be protected. The four jobs a suite covers are:
- Key exchange — how the two sides agree on a shared secret without sending it across the network.
- Authentication — how the server proves its identity, tied to the type of key in its certificate.
- Bulk encryption — the fast symmetric cipher that scrambles the actual data once the connection is up.
- Integrity — how each message is checked for tampering, and the hash used in deriving keys.
Reading a TLS 1.2 Suite, Left to Right
The classic format packs all four jobs into one hyphenated name. Take the common example and split it apart:
ECDHE - RSA - AES128-GCM - SHA256
│ │ │ │
key auth bulk cipher hash
exch. + mode (integrity /
key derivation)| Segment | Job | What it means here |
|---|---|---|
ECDHE | Key exchange | Elliptic-curve Diffie-Hellman, ephemeral — a fresh key each session, giving forward secrecy |
RSA | Authentication | The server's certificate uses an RSA key to prove identity |
AES128-GCM | Bulk cipher | AES with a 128-bit key, in GCM mode (encryption + built-in integrity) |
SHA256 | Hash | SHA-256, used for key derivation and as the suite's hash function |
Read that way, the intimidating string becomes a sentence: "agree on a key with ephemeral elliptic-curve Diffie-Hellman, prove identity with RSA, encrypt the data with 128-bit AES in GCM mode, and use SHA-256 for hashing." Every secure suite tells the same kind of story; only the algorithms change.
The Pieces That Actually Matter
Once you can parse the name, two segments deserve closer attention because they carry most of the security weight.
The key exchange tells you whether the connection has forward secrecy. Anything beginning with ECDHE or DHE — the "E" standing for ephemeral — generates a throwaway key per session, so that even if the server's long-term private key is later stolen, past recordings cannot be decrypted. A suite using plain RSA key exchange (now removed from modern TLS) lacked this, which is why it was retired. This is important enough to have its own page on perfect forward secrecy.
The cipher mode tells you how integrity is handled. GCM and ChaCha20-Poly1305 are authenticated encryption — they encrypt and verify in one operation, which is both faster and far less error-prone. The older CBC mode encrypts only, bolting on a separate integrity check, and that two-step arrangement was the root of several well-known attacks. Seeing GCM in a suite is a good sign; seeing CBC is a hint the connection is leaning on legacy cryptography.
How TLS 1.3 Cleaned Up the Mess
The 1.2-era naming had a problem: the menu of possible suites grew enormous, and many combinations were weak, obsolete, or subtly broken. Negotiating from a long list also gave attackers room to push connections toward the worst option. TLS 1.3 took a blade to all of it.
First, it shortened the names. A TLS 1.3 suite looks like TLS_AES_128_GCM_SHA256 — just the bulk cipher and the hash. The key exchange and authentication are negotiated separately rather than baked into the suite name, because in TLS 1.3 they are always ephemeral and strong, so there is nothing left to choose badly. Second, it slashed the list to a tiny set of vetted, modern suites, every one of which uses authenticated encryption and forward secrecy. The practical upshot is striking: under TLS 1.3 there is no such thing as a weak cipher suite to accidentally select. Simply supporting TLS 1.3 hands you good cryptography by default.
Why This Negotiation Is Worth Caring About
The reason cipher suites get so much attention in security audits is that the suite is where a TLS connection's strength is actually decided. A site can have a perfect certificate and still be exposed if it permits an ancient, breakable suite for the sake of old clients. The negotiation is also a tempting target: a "downgrade attack" tries to trick the two sides into choosing a weaker suite than both could manage — which is exactly why the handshake's Finished message hashes the whole exchange to detect tampering. For the broader machinery of certificates and trust that the chosen suite operates within, see how TLS works and the role of certificate authorities.
Frequently Asked Questions
What is a cipher suite?
A named bundle of cryptographic algorithms a TLS connection uses together — for key exchange, authentication, bulk encryption, and integrity. During the handshake the client and server agree on one suite they both support, and that choice determines how the connection is secured.
How do you read a cipher suite name?
In TLS 1.2, a name like ECDHE-RSA-AES128-GCM-SHA256 reads left to right: ECDHE is the key exchange, RSA the authentication, AES128-GCM the bulk cipher and mode, and SHA256 the hash. Each segment names the algorithm doing one job in the connection.
How did TLS 1.3 change cipher suites?
It shortened names to just the bulk cipher and hash, e.g. TLS_AES_128_GCM_SHA256, negotiating key exchange and authentication separately. Only a handful of strong, modern suites remain — all with authenticated encryption and forward secrecy — removing the weak combinations behind many older flaws.
What is the difference between AES-GCM and AES-CBC?
Both use AES, but the mode differs. GCM is authenticated encryption — it encrypts and verifies integrity in one step, faster and safer. CBC encrypts only and needs a separate integrity check, a combination behind several attacks. Modern suites favour GCM.
Which cipher suite is the most secure?
There is no single best, but strong options share traits: an ephemeral key exchange like ECDHE for forward secrecy, an authenticated cipher like AES-GCM or ChaCha20-Poly1305, and a modern hash like SHA-256. Every TLS 1.3 suite meets these, so using TLS 1.3 is the easiest way to get a strong suite.