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. Our dedicated guide to perfect forward secrecy explains the mechanism and the attack it defends against in depth.
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.
Frequently Asked Questions
Answers to common questions about certificates and our services.
What is a cipher suite in simple terms?
A cipher suite is a named bundle of cryptographic algorithms that a client and server agree to use for a single TLS connection. Think of it as a recipe: it specifies how the two sides exchange a shared secret without anyone listening in, how the server proves it is who it claims to be, how the actual data is scrambled, and how each message is checked for tampering. Both sides keep a list of suites they're willing to use, and during the handshake they settle on one they have in common. The name you'll see in a browser's connection details — something like TLS_AES_128_GCM_SHA256 — is just shorthand for that whole combination of algorithms.
How do I read a cipher suite name like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256?
Read it left to right as a sequence of choices. TLS is the protocol. ECDHE is the key exchange — Elliptic Curve Diffie-Hellman Ephemeral, which gives you forward secrecy. RSA is the authentication algorithm, meaning the server proves its identity with an RSA certificate. WITH separates the negotiation half from the data-protection half. AES_128_GCM is the bulk cipher: AES with a 128-bit key in Galois/Counter Mode, which both encrypts and authenticates the data. SHA256 is the hash used for the handshake and key derivation. So the full name tells you exactly how the connection is keyed, who is trusted, how data is encrypted, and how integrity is verified.
Why are TLS 1.3 cipher suite names so much shorter?
Because TLS 1.3 took the choices out of the suite. In TLS 1.2 a suite had to spell out the key exchange and the authentication method as well as the cipher and hash, which is why names were long. TLS 1.3 negotiates key exchange and the certificate's signature algorithm separately, so the cipher suite now only names the bulk cipher and its hash — for example TLS_AES_128_GCM_SHA256. There are just five suites defined for TLS 1.3, all of them modern authenticated-encryption (AEAD) algorithms, and forward secrecy is mandatory. Fewer, safer options is the whole point.
Which cipher suites should I disable?
Disable anything without forward secrecy or built-in authentication, and anything built on broken primitives. Concretely: turn off RC4 (prohibited by RFC 7465), 3DES and other 64-bit block ciphers (vulnerable to the Sweet32 attack), export-grade and NULL ciphers, anything using plain RSA key exchange (no ECDHE/DHE, so no forward secrecy), and old CBC-mode suites where AEAD alternatives exist. The simplest safe path is to allow only TLS 1.2 and TLS 1.3, and within TLS 1.2 keep only ECDHE suites that use AES-GCM or ChaCha20-Poly1305. Mozilla's Intermediate profile encodes exactly this and is a sensible default for a public site.
Do cipher suites depend on whether I use an RSA or ECDSA certificate?
Yes, in TLS 1.2 the authentication part of the suite must match your certificate's key type. A suite named TLS_ECDHE_RSA_… requires an RSA certificate, while TLS_ECDHE_ECDSA_… requires an ECDSA (elliptic-curve) certificate. If your server only presents an RSA certificate, it can't negotiate an ECDSA suite, and vice versa. Some servers are configured with both certificate types and pick whichever matches the client's preferences. In TLS 1.3 this coupling is gone from the suite name — the signature algorithm is negotiated separately — but your certificate's key type still determines which signatures the server can offer.
Is a longer key, like AES-256, meaningfully more secure than AES-128?
For almost every website the difference is academic. AES-128 is considered secure against any feasible brute-force attack today, so AES-256 doesn't make a practical site measurably safer against current threats. AES-256 is often required by specific compliance regimes or chosen as a hedge against future cryptanalysis, and it carries a small performance cost. What matters far more than 128 versus 256 is using an AEAD mode (GCM or ChaCha20-Poly1305) with a forward-secret key exchange. Get those right and either key length is fine; get them wrong and a 256-bit key won't save you.