Open the security details of any HTTPS connection and you'll find a cryptic-looking label such as TLS_AES_128_GCM_SHA256 or TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. That string is the cipher suite — the exact set of algorithms your browser and the server agreed to use to protect the connection. It decides how a shared key is established, how the server proves its identity, how your data is encrypted, and how each packet is checked for tampering. This guide breaks the name down piece by piece, explains why forward secrecy is the part that matters most, shows how TLS 1.3 dramatically simplified the picture, and gives you a clear rule for which suites to keep and which to switch off.
In short
A cipher suite bundles the algorithms for one TLS connection: key exchange, authentication, bulk encryption, and integrity. In TLS 1.2 the name spells out all of these, which is why it's long. In TLS 1.3 key exchange and signatures are negotiated separately, so the suite only names the cipher and hash — and all five available suites are modern AEAD ciphers with mandatory forward secrecy. The practical advice: allow only TLS 1.2 and 1.3, and within 1.2 keep only ECDHE suites using AES-GCM or ChaCha20-Poly1305.
What a cipher suite is
Encrypting a connection isn't a single operation — it's several distinct cryptographic jobs working together. The two sides need to agree on a secret key without an eavesdropper learning it. The client needs assurance it's really talking to the right server and not an impostor. The data flowing back and forth needs to be scrambled. And every message needs an integrity check so a tampered packet is detected and rejected. A cipher suite is simply a pre-defined combination of algorithms that covers all of those jobs at once, given a single short name.
Bundling them this way keeps negotiation simple. Rather than haggling over each algorithm independently, the client offers a ranked list of complete suites it supports, and the server picks one. That negotiation happens at the very start of the connection, during the TLS handshake. If you want the full picture of where this fits, our explainer on how SSL works walks through the handshake step by step — the cipher suite is the menu choice both sides make in that exchange.
Anatomy of a cipher suite name
The names look intimidating, but they're just a fixed sequence of choices read left to right. Take a classic TLS 1.2 suite and split it at the word WITH:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
| Part | Meaning |
|---|---|
| TLS | The protocol family the suite belongs to. |
| ECDHE | Key exchange. Elliptic Curve Diffie-Hellman Ephemeral — how the two sides agree on a shared secret. The "ephemeral" part is what delivers forward secrecy. |
| RSA | Authentication. How the server proves its identity — here, with an RSA certificate. You'll also see ECDSA. |
| AES_128_GCM | Bulk cipher. AES with a 128-bit key in Galois/Counter Mode — the algorithm that actually encrypts (and authenticates) your data. |
| SHA256 | Hash. Used in key derivation and the handshake's integrity checks. |
Once you can split a name at WITH — negotiation on the left, data protection on the right — every TLS 1.2 suite becomes readable. A suite is only as strong as its weakest part, which is why a single outdated component is enough reason to disable the whole suite.
The four jobs inside a suite
1. Key exchange
Establishes a shared secret over a channel an attacker may be watching. Modern suites use ECDHE (or DHE), where a fresh key pair is generated for each connection. Older suites used static RSA key exchange, where the client encrypts the secret to the server's long-term public key — convenient, but it means no forward secrecy.
2. Authentication
Proves the server is genuine by signing part of the handshake with the private key behind its certificate. The suite names the signature algorithm — RSA or ECDSA — and it must match your certificate's key type. The trade-offs between the two are covered in our ECC vs RSA comparison.
3. Bulk encryption
The workhorse that encrypts the actual traffic, using the key established above. Today this should be an AEAD cipher — AES-GCM or ChaCha20-Poly1305 — which encrypts and authenticates in one step. ChaCha20 often wins on devices without AES hardware acceleration, such as many phones.
4. Integrity / hash
Detects tampering and feeds the key-derivation function. With AEAD ciphers the message authentication is built into the cipher itself, so the trailing hash (e.g. SHA256 or SHA384) is used mainly for the handshake. Older non-AEAD suites bolted on a separate HMAC, which historically led to a string of padding-related attacks.
Why forward secrecy matters most
If you take one thing from a cipher suite name, make it the key-exchange field. A suite that begins with ECDHE or DHE provides forward secrecy: each connection negotiates a fresh, single-use key, and that key is thrown away when the session ends. A suite without the "E" — plain RSA key exchange — does not.
The difference is stark in one specific scenario. Imagine an attacker records all your encrypted traffic today and steals your server's private key a year from now. With a non-forward-secret suite, that single stolen key unlocks every recorded session retroactively — months of "encrypted" traffic decrypted in bulk. With forward secrecy, the stolen key can't reconstruct the ephemeral per-session keys, so the recorded traffic stays protected. This is also the threat model behind interest in post-quantum cryptography: "harvest now, decrypt later" only works against connections that lack forward secrecy or use a key exchange a future computer could break.
The quick test
Scan a TLS 1.2 suite for ECDHE or DHE at the start. If it's there, you have forward secrecy. If the suite jumps straight to TLS_RSA_WITH_…, you don't — and that's a suite worth disabling. In TLS 1.3 this worry disappears entirely: forward secrecy is mandatory, so every TLS 1.3 connection has it.
How TLS 1.3 simplified cipher suites
TLS 1.3 (RFC 8446) rethought what a cipher suite should even contain. Because the protocol always uses ephemeral key exchange and negotiates the certificate's signature algorithm in a separate handshake field, those parts no longer belong in the suite name. What's left is just the bulk cipher and the hash — which is why TLS 1.3 names are so much shorter:
| TLS 1.3 suite | Notes |
|---|---|
| TLS_AES_128_GCM_SHA256 | The mandatory-to-implement baseline; fast and widely used. |
| TLS_AES_256_GCM_SHA384 | Larger key for higher security margins or compliance needs. |
| TLS_CHACHA20_POLY1305_SHA256 | Excels on devices without AES hardware acceleration. |
| TLS_AES_128_CCM_SHA256 | CCM mode; mainly seen in constrained / IoT contexts. |
| TLS_AES_128_CCM_8_SHA256 | Shortened-tag CCM variant for very constrained devices. |
That's the entire list — five suites, all of them AEAD, all forward-secret. In practice the first three carry virtually all real-world TLS 1.3 traffic, and most servers don't even let you reorder them because all the remaining choices are already safe. This deliberate pruning of weak options is one of the headline improvements; our deep dive on TLS 1.3 vs TLS 1.2 covers the handshake changes that made it possible.
Weak and deprecated suites to disable
Most cipher-suite hardening is really about removal — switching off the legacy options a server may still accept for backward compatibility. The usual offenders:
- RC4. A stream cipher with known biases, formally prohibited in TLS by RFC 7465 and removed from browsers years ago. There is no safe use of RC4 today.
- 3DES and other 64-bit block ciphers. Vulnerable to the Sweet32 birthday attack (CVE-2016-2183), which can recover data from long-lived connections. Disable any suite naming
3DESorDES. - Export-grade and NULL ciphers. Export suites use deliberately weak keys from a bygone regulatory era; NULL suites provide authentication but no encryption at all. Both should always be off.
- Static RSA key exchange. Suites like
TLS_RSA_WITH_…work fine but provide no forward secrecy, so a future key compromise exposes past traffic. Prefer ECDHE equivalents. - Old CBC-mode suites. Non-AEAD CBC suites have a long history of padding-oracle and related attacks. Where an AES-GCM or ChaCha20-Poly1305 alternative exists, use it instead.
Closely related is protocol version: RFC 8996 deprecates TLS 1.0 and 1.1 outright, and those old protocols only support the weak suites above. Allowing just TLS 1.2 and 1.3 removes most bad suites automatically. If users hit handshake failures after you tighten things up, our guide to SSL certificate errors covers the protocol- and cipher-mismatch messages you might see.
How the client and server pick a suite
Suite selection happens in the first two handshake messages. It's a short negotiation, but the order of preference is configurable and matters:
- Client offers a list. The browser's ClientHello carries every cipher suite it's willing to use, in its preferred order.
- Server chooses one. The server compares that list against its own enabled suites and selects a match. Many servers are configured to honor the server's preference order rather than the client's, so the administrator controls which suite wins when several are mutually supported.
- No overlap means no connection. If the two share no acceptable suite — say a very old client that only offers RC4 meets a properly hardened server — the handshake fails rather than falling back to something insecure. That failure is a feature, not a bug.
You can see exactly what a server offers with a single OpenSSL command — openssl s_client -connect example.com:443 reports the negotiated suite, and tools that probe each suite in turn will map the full set. Our OpenSSL commands cheat sheet lists the handshake-inspection commands worth keeping handy.
Choosing and configuring your suites
You rarely need to hand-pick individual suites. The reliable approach is to start from a vetted profile and adjust only if you have a specific reason. The widely used reference is Mozilla's Server Side TLS guidance and its configuration generator, which publishes ready-made settings for Apache, Nginx, IIS, and more across three profiles:
Intermediate — the sensible default
Allows TLS 1.2 and 1.3 with a curated set of ECDHE + AEAD suites. It balances strong security with broad client compatibility, which is why it's the right starting point for most public websites.
Modern — TLS 1.3 only
Permits only TLS 1.3 and its five AEAD suites. The strongest option, but it locks out older clients, so use it when you fully control your audience (internal apps, APIs, modern-only services).
Old — only if you truly must
Re-enables legacy protocols and suites for ancient clients. It reintroduces known weaknesses, so treat it as a temporary bridge while you retire those clients, not a destination.
Whichever profile you pick, generate the config from a trusted source, apply it, and then verify the live result rather than trusting the file. Pair your cipher configuration with HSTS so browsers stick to HTTPS, and walk through our SSL configuration guide if you're setting up a certificate from scratch. The goal is simple: only TLS 1.2 and 1.3, only forward-secret AEAD suites, and nothing legacy left switched on.