TLS Cipher Suites Reference
Decode cipher suite names, see which are secure and which are deprecated. Modern recommendations.
What a cipher suite tells you
A TLS cipher suite is a list of cryptographic algorithms used together. A typical TLS 1.2 cipher suite name looks like:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Decoded:
- ECDHE — key exchange (Elliptic Curve Diffie-Hellman Ephemeral). Forward secrecy.
- RSA — authentication (server's cert uses RSA)
- AES_256_GCM — symmetric cipher (256-bit AES, authenticated encryption)
- SHA384 — hash for HMAC and key derivation
TLS 1.3 simplifies dramatically — only AEAD cipher and hash, since key exchange and auth are negotiated separately:
TLS_AES_256_GCM_SHA384
Recommended modern cipher suites
| Cipher Suite | TLS | Why |
|---|---|---|
| TLS_AES_128_GCM_SHA256 | 1.3 | Mozilla "Modern" baseline. Fast on AES-NI hardware. |
| TLS_AES_256_GCM_SHA384 | 1.3 | Stronger margin. Default for many TLS 1.3 servers. |
| TLS_CHACHA20_POLY1305_SHA256 | 1.3 | Best for mobile / CPU without AES-NI. |
| ECDHE-ECDSA-AES128-GCM-SHA256 | 1.2 | ECDSA cert — smaller, faster handshake. |
| ECDHE-RSA-AES256-GCM-SHA384 | 1.2 | Most common in production with RSA certs. |
| ECDHE-RSA-CHACHA20-POLY1305 | 1.2 | ChaCha20 alternative for mobile. |
Avoid (deprecated or broken)
| Cipher | Problem |
|---|---|
| Anything with RC4 | Broken — biased keystream. Deprecated 2015. |
| Anything with DES or 3DES | Sweet32 attack practical. |
| Anything with EXPORT_ | Intentionally weakened. FREAK attack. |
| Anything with NULL_ | No encryption at all. |
| Anything with anon_ | No authentication. Vulnerable to MITM. |
| Anything with MD5 | Broken hash. |
| Static RSA key exchange (no DHE/ECDHE) | No forward secrecy. |
Components, in detail
Key exchange
| Algo | Status | Notes |
|---|---|---|
| ECDHE | ✓ Preferred | Elliptic-curve DH, ephemeral. Forward secrecy. |
| DHE | ✓ OK (slower) | Classical DH, ephemeral. Forward secrecy. |
| RSA | ✗ Avoid | Static key exchange. No forward secrecy. |
| PSK | Niche | Pre-shared key. Used in IoT, TLS 1.3 session resumption. |
Symmetric encryption
| Cipher | Status | Notes |
|---|---|---|
| AES-GCM (128 or 256) | ✓ Preferred | AEAD, hardware-accelerated. |
| ChaCha20-Poly1305 | ✓ Preferred | AEAD, fast without AES-NI (mobile). |
| AES-CBC | OK in TLS 1.2+ only | Padding oracle risk if not done carefully. |
| 3DES | ✗ Broken | Sweet32. 112-bit effective. |
| RC4 | ✗ Broken | Forbidden in modern TLS. |
If you're configuring TLS today, copy Mozilla's Intermediate config from wiki.mozilla.org/Security/Server_Side_TLS. Works for ~99% of clients, supports modern ciphers, audited. Don't roll your own list.
Why cipher suite selection matters in practice
The cipher suites a server accepts determine which clients can connect securely and how strong the resulting connection is. Get this wrong and either legacy clients can't connect (bad for business) or modern clients get downgraded to weaker crypto (bad for security). Every TLS administrator faces this tradeoff eventually.
Modern practice has shifted significantly since 2018 or so. TLS 1.3 removed the legacy of negotiable cipher suites for key exchange and authentication — those are now fixed. What remains negotiable in TLS 1.3 is just the AEAD cipher and hash. This makes TLS 1.3 much simpler and much more secure by default. A TLS 1.3 server offers a small handful of AEAD ciphers (AES-GCM and ChaCha20-Poly1305 being the main two) and picks the best mutually-supported one with the client.
TLS 1.2 still exists on the wire because a meaningful fraction of clients don't support 1.3. Getting TLS 1.2 configuration right is where the operator work still lives. The Mozilla Server Side TLS guide (referenced in the callout above) is the pragmatic default — copy Intermediate configuration, adjust only if you have specific constraints.
How to read a cipher suite string
A TLS 1.2 cipher suite name like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 encodes four decisions:
- Key exchange (ECDHE): how the client and server agree on a shared secret. ECDHE means ephemeral elliptic-curve Diffie-Hellman, which provides forward secrecy — a compromise of the server's long-term private key doesn't retroactively decrypt past sessions.
- Authentication (RSA): how the server proves its identity. RSA uses an RSA private key. Modern alternatives include ECDSA (with an elliptic-curve certificate).
- Bulk encryption (AES_256_GCM): how session data is encrypted. AES-256 in GCM mode is authenticated encryption, which prevents ciphertext manipulation attacks.
- MAC hash (SHA384): what hash is used for the handshake integrity check. Not directly relevant to bulk encryption in AEAD suites (GCM includes its own authentication).
TLS 1.3 cipher suites are much simpler: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256. Key exchange and authentication happen through separate mechanisms in the handshake.
What to actually deploy
My default modern config for anything I'm setting up in 2026:
- Enable TLS 1.3. Every modern web server supports it. Every modern client supports it. The performance and security benefits over 1.2 are real.
- Enable TLS 1.2 for compatibility. Some legacy clients still need it. Restrict to strong cipher suites only.
- Disable TLS 1.1, TLS 1.0, and SSLv3. Removed by browsers years ago. If you have specific clients that need them, replace those clients.
- Prefer ECDHE key exchange. Provides forward secrecy. Fast on modern hardware.
- Prefer AEAD ciphers. AES-GCM on modern CPUs with AES-NI, ChaCha20-Poly1305 as a backup for mobile devices without AES hardware acceleration.
- Prefer ECDSA certificates for new deployments. Smaller certificates, faster handshakes. Use RSA certificates only if you need compatibility with clients that don't support ECDSA (rare in 2026).
Common configuration mistakes
Prioritizing broad compatibility over security
Enabling every cipher suite in the book "just in case" some client needs one is how you end up serving weak crypto to modern clients that would have negotiated something better. Restrict to strong cipher suites and let the small fraction of legacy clients either upgrade or use an alternative access method.
Copying old tutorial values
Copy-paste configuration from a 2016 tutorial is one of the most reliable ways to end up with 3DES enabled. Copy configuration from current sources (Mozilla's SSL Config Generator, or a recent hardening guide from a reputable vendor). Recheck at least yearly.
Forgetting to renew certificates
Not directly a cipher suite issue but shows up in the same audit. Enable automated certificate renewal (ACME, Certbot, cert-manager). Manual renewal is a source of outages.
Not testing external
Run your site through SSL Labs' server test after any configuration change. Grades below A- indicate real issues worth investigating. Grades of B or lower usually mean an outdated protocol is still enabled or a weak cipher is being offered.
Forward secrecy specifically
Forward secrecy (also called perfect forward secrecy, PFS) means that compromise of the server's long-term private key doesn't retroactively decrypt past recorded sessions. This is achieved by using ephemeral key exchange — a fresh key pair is generated for each session and discarded after.
Every ECDHE cipher suite provides forward secrecy. Every DHE (non-elliptic-curve ephemeral Diffie-Hellman) cipher suite does too, though DHE is slower. Old RSA key exchange suites don't provide forward secrecy and shouldn't be used in modern configurations.
Why this matters: if an attacker records your encrypted traffic today and steals your private key next year, they can decrypt the recording only if the cipher suite didn't provide forward secrecy. Modern configurations make this attack impossible.
When "post-quantum" comes up
Quantum computers, if they become powerful enough, will break the elliptic-curve and RSA public-key cryptography currently used in TLS. This isn't an immediate threat but it's on the industry radar.
TLS 1.3 has been extended with hybrid key exchange (X25519+Kyber, for example) that combines classical and post-quantum algorithms so that even if one is broken, the other still provides security. Cloudflare and Google have deployed these hybrid schemes at scale. In 2026, they're production-ready but not yet universally required.
For most operators, this doesn't require action yet. When post-quantum becomes the required default, it'll be a configuration flip similar to enabling TLS 1.3 a few years ago.
Related tools
To inspect the actual certificate a site is currently serving, use the SSL/TLS Cert Inspector. To audit HTTP-level security headers (HSTS, CSP, X-Frame-Options) that pair with proper TLS, use the HTTP Headers Inspector. External tools worth knowing: SSL Labs' Server Test (ssllabs.com/ssltest), which grades a site's overall TLS configuration.