Modern cipher suite preference · Web Quality Index

TL;DR: A cipher suite is the bundle of cryptographic algorithms a TLS connection actually uses. Modern AEAD suites (AES-GCM, ChaCha20-Poly1305) authenticate and encrypt in one step and dodge entire classes of attacks. CBC suites still work but are legacy. RC4 and 3DES are broken — never negotiate them. Aim for AEAD-only, turn on TLS 1.3, and the problem mostly solves itself.

What is it?

When two parties complete a TLS handshake, they don’t just agree to “use TLS.” They agree on a specific bundle of algorithms that govern the rest of the conversation. That bundle is the cipher suite, and its name encodes everything you need to know.

Take the TLS 1.2 cipher suite name TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and walk it left to right:

Segment	Role	What this one says
`TLS`	Protocol family	TLS (not the older SSL).
`ECDHE`	Key exchange	Elliptic-curve Diffie-Hellman, ephemeral. Each session gets fresh key material — that’s forward secrecy.
`RSA`	Authentication	The server’s certificate uses an RSA key, and the handshake uses RSA to prove the server controls it.
`AES_256`	Bulk cipher	AES with a 256-bit key encrypts the actual application data.
`GCM`	Cipher mode	Galois/Counter Mode — an AEAD mode that combines encryption and authentication in one step.
`SHA384`	Hash / PRF	SHA-384 inside the handshake’s pseudo-random function and HMAC.

TLS 1.3 cleaned all of this up. A 1.3 cipher suite name like TLS_AES_256_GCM_SHA384 is shorter for a reason — there’s no key exchange or authentication algorithm baked into the suite anymore. Those are negotiated separately, and TLS 1.3 only allows ephemeral key exchange (X25519, ECDHE on standard curves, or hybrid PQ) and only allows AEAD bulk ciphers. So a 1.3 suite name is just bulk cipher + mode + hash, and the rest is implicit in the protocol.

Why does it matter?

Three categories of cipher suite live on the public internet today. They are not equivalent.

AEAD suites (AES-GCM, ChaCha20-Poly1305) — what you want. “Authenticated Encryption with Associated Data” means encryption and authentication happen together, atomically, in one cryptographic operation. There’s no separate MAC step that can be skipped, reordered, or implemented wrong. AEAD modes structurally prevent the entire family of “manipulate the ciphertext and watch what the server does” attacks — including padding oracles, BEAST, Lucky 13, and POODLE-style exploits.

CBC suites — legacy, technically still safe if you’re careful. CBC (Cipher Block Chaining) plus a separate MAC works in theory but has a graveyard of historical attacks: BEAST (2011), Lucky 13 (2013), POODLE (2014), and a long tail of padding-oracle variants. Modern TLS stacks have mitigations for all of them, but the safest path is just to not negotiate CBC at all. There’s no longer a real-world client that needs CBC and can’t speak AEAD.

RC4 and 3DES — broken. Don’t. RC4 has been considered cryptographically broken since 2013 (the keystream is biased, and at scale you can recover plaintext). 3DES is vulnerable to Sweet32 birthday attacks at 64-bit block sizes. Both were formally banned from TLS by the IETF (RFC 7465 for RC4, RFC 8429 deprecating 3DES). If your server still negotiates either, that’s a meaningful security finding — not a stylistic preference.

Real-world analogy

Cipher suites are like hotel-room safes.

The modern electronic ones (AEAD) check the lock and the contents every time the door closes. Tampering with the door without the code trips the alarm — by design.

The mechanical combination ones (CBC) work fine if installed perfectly. But there’s a stack of YouTube videos about shimming techniques, and if the staff who installed yours rushed it, a guest with the right tool can pop it. Nothing wrong with the design in isolation; everything depends on flawless implementation.

The 1990s three-digit-dial ones (RC4, 3DES) you can pop with a fingernail file. They were state-of-the-art when they shipped; they aren’t now, and nobody serious uses them. If you find one in a hotel room in 2026, the question is why.

A short list of cipher suites you actually want

If you only enable these five, you’re done:

Cipher suite	Protocol	Why
`TLS_AES_256_GCM_SHA384`	TLS 1.3	Modern, fast, AEAD, ubiquitous client support.
`TLS_AES_128_GCM_SHA256`	TLS 1.3	Same family, smaller key — the most-negotiated suite on the internet.
`TLS_CHACHA20_POLY1305_SHA256`	TLS 1.3	AEAD without AES-NI hardware — faster on mobile and older ARM CPUs.
`ECDHE-ECDSA-AES256-GCM-SHA384`	TLS 1.2	AEAD + ECDSA cert. The 1.2 fallback for ECDSA-issued certs.
`ECDHE-RSA-AES256-GCM-SHA384`	TLS 1.2	AEAD + RSA cert. The 1.2 fallback for RSA-issued certs.

Skip everything else. CBC variants, static-RSA suites, anything with RC4 or 3DES in the name, anything with EXPORT or NULL — all of them are either legacy ballast or actively dangerous.

How WQI measures this

We grade cipher suite preference as factor WEBQ-87 in the Security category. The signal is the negotiated cipher suite name observed during the live TLS handshake — Go’s tls.CipherSuiteName in our Container probe, or Cloudflare URL Scanner’s securityDetails when the Container path can’t reach a host.

Result	Score	What it means
Pass	100	AEAD-only — AES-GCM or ChaCha20-Poly1305 negotiated.
Warn	60	CBC suite negotiated. Acceptable today, not modern.
Fail	0	RC4 or 3DES negotiated. Broken.

We score the negotiated suite, not the full advertised list. If your server prefers AES-GCM but still allows CBC as a fallback, you’ll pass on most handshakes — but a client that only offers CBC will pull a CBC suite out of you and the audit will catch it. The clean answer is to drop the legacy suites entirely.

What good looks like

AEAD only. TLS 1.3 enabled. That’s the whole bar.

TLS 1.3 is a free win here because the protocol itself only allows AEAD bulk ciphers — there is no way to negotiate CBC, RC4, or 3DES inside a 1.3 connection. Enabling 1.3 is therefore a partial fix all on its own: any client that speaks 1.3 (which is nearly all of them in 2026) is automatically on AEAD. The remaining work is making sure your TLS 1.2 fallback list doesn’t carry CBC or worse for clients that haven’t upgraded.

How to fix it

Nginx. In your server block:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE+AESGCM:ECDHE+CHACHA20:!aNULL:!MD5:!DSS;
ssl_prefer_server_ciphers on;

The !aNULL:!MD5:!DSS exclusions are belt-and-suspenders against edge-case suites that shouldn’t be in the default list anyway. Note that TLS 1.3 cipher selection is controlled by ssl_conf_command (OpenSSL 1.1.1+), not ssl_ciphers — but the OpenSSL defaults for 1.3 are already AEAD-only, so you usually don’t need to touch them.

Apache. In your VirtualHost or main config:

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE+AESGCM:ECDHE+CHACHA20:!aNULL:!MD5:!DSS
SSLHonorCipherOrder on

Caddy. Caddy ships with a sensible AEAD-only default — no config needed. If you want to be explicit, set protocols tls1.2 tls1.3 in your TLS block.

Cloudflare. Dashboard: SSL/TLS → Edge Certificates → Cipher Suites → Modern. The “Modern” preset matches Mozilla’s modern profile (TLS 1.3 + AEAD-only TLS 1.2). The “Compatible” preset includes CBC for legacy client support — only choose that if you have a real, named integration that demands it.

Verify with nmap:

nmap --script ssl-enum-ciphers -p 443 yourdomain.com

You should see only ..._AES_..._GCM_... and ..._CHACHA20_POLY1305_... suites listed, and an “A” or higher grade on the script’s summary line. Anything ending in _CBC_... is a CBC suite and should be removed.

Common pitfalls

Native mobile clients with hard-coded cipher lists. Some apps (especially older iOS/Android SDKs and embedded automotive stacks) ship with a frozen 2018-era cipher list that only knows CBC. If you drop CBC entirely and they call you, the connection fails. Audit your real client mix before tightening.
Internal partner integrations frozen in time. A B2B partner’s legacy backend may still negotiate 3DES or RC4 because it’s running on a Java 7 stack nobody has touched in eight years. Don’t make their bug your security finding — fix it on their side or move the integration behind a modern proxy.
Load balancer and origin disagreement. If you terminate TLS at a CDN or load balancer and re-encrypt to your origin, both legs need to be modern. A “Modern” Cloudflare profile in front of an origin that only speaks RSA-CBC means the user-to-edge leg is fine but the edge-to-origin leg is still legacy. Audit both.
Confusing TLS 1.2 cipher list syntax with TLS 1.3. TLS 1.3 has five suites total, all AEAD, configured separately in OpenSSL. Don’t try to disable a 1.3 suite by adding !TLS_AES_128_GCM_SHA256 to your 1.2 cipher string — it does nothing, and you may break parsing.
Changing config without reload. nginx -s reload and apachectl graceful don’t always pick up TLS context changes cleanly under heavy load. After a cipher list change, do a full restart in a maintenance window and verify with nmap from outside the network.