Cipher suites explained: TLS 1.3 and forward secrecy

A cipher suite is the named bundle of algorithms a TLS connection uses. In TLS 1.2, one name such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 fixes the key exchange, the authentication method, the encryption and the hash; in TLS 1.3, the name covers only the encryption and the hash, because key exchange and signatures are negotiated separately. A sound server today allows the TLS 1.3 suites plus a few ECDHE suites with AES-GCM or ChaCha20 for TLS 1.2, and nothing else.

What a cipher suite is

At the start of every TLS connection, the client sends the list of cipher suites it supports, and the server picks one; our guide to how SSL/TLS works shows where this fits in the handshake. If they share none, the handshake fails. If the server's list includes weak options, a badly configured or old client can end up using them without anyone noticing.

Each suite has a two-byte code in the IANA TLS Cipher Suites registry, which also has a "Recommended" column. Since December 2025, that column can say Y (recommended), N (not recommended, often just niche) or D (discouraged), which makes the registry a quick way to check an unfamiliar name.

Reading a TLS 1.2 suite name

TLS 1.2 names pack four decisions into one string. Take the suite with code 0xC0,0x2F:

OpenSSL, and therefore nginx and many other servers, spells the same suite differently: ECDHE-RSA-AES128-GCM-SHA256. Keep both naming styles in mind when you compare documentation with a config file.

Now compare an old favourite, TLS_RSA_WITH_AES_128_CBC_SHA (code 0x00,0x2F). With only one algorithm before "WITH", RSA does both jobs: it authenticates the server and carries the session secret, encrypted to the server's key. There is no forward secrecy. The cipher runs in CBC mode with a SHA-1-based integrity check, a combination behind years of attacks. Since July 2026, IANA marks it "D", because RFC 10015 forbids RSA key exchange in TLS 1.2. The name tells you all of this if you know how to read it.

TLS 1.3's shorter list

TLS 1.3 defines just five suites, and their names follow a simpler pattern: TLS, the authenticated encryption algorithm, and the hash.

The list comes from RFC 9846, the current TLS 1.3 specification. Key exchange and authentication moved out of the suite name into separate extensions: supported groups and key shares (such as x25519, secp256r1 and the post-quantum hybrid X25519MLKEM768) and signature algorithms (such as ECDSA, RSA-PSS and Ed25519). So "TLS_AES_128_GCM_SHA256" tells you nothing about whether a connection is protected against future quantum computers; the negotiated group does, as our guide to post-quantum cryptography explains. TLS 1.3 suites can't be used with TLS 1.2, and TLS 1.2 suites can't be used with TLS 1.3.

The difference between AES-GCM and the older CBC mode is explained in our guide to AES-GCM vs AES-CBC, and why ChaCha20 suits some phones in block vs stream ciphers.

Perfect forward secrecy

Perfect forward secrecy means that stealing a server's long-term private key later doesn't let anyone decrypt conversations recorded earlier. It comes from ephemeral key exchange: each connection's secret is agreed with fresh Diffie-Hellman values that are deleted afterwards. Our guide to Diffie-Hellman key exchange shows why the recorded messages alone aren't enough.

A worked scenario, with illustrative details: someone records encrypted traffic between students and a course platform for a year, from a compromised router or a network tap. Later, a server breach leaks the platform's certificate key.

• With TLS_RSA suites, every recorded session can now be decrypted, because each one's secret was encrypted to that key.
  
  
• With ECDHE suites, none can. The key only ever signed the handshakes; the secrets that encrypted the traffic no longer exist anywhere.
  
  

That is why the IETF's TLS guidance, RFC 9325, says implementations must support and prefer forward-secret suites, and why TLS 1.3 offers nothing else for certificate-based handshakes. Two gaps remain even with the right suites. In TLS 1.2, session tickets are encrypted with a server-side key, and a long-lived ticket key that leaks exposes the sessions resumed with it, so rotate ticket keys. In TLS 1.3, 0-RTT early data isn't guaranteed forward secrecy.

Weak cipher suites to remove

The July 2026 changes come from RFC 10015, which also marked the affected suites "D" in the IANA registry. Finite-field DHE remains acceptable inside TLS 1.3, where its earlier problems don't apply.

A sensible configuration today

Mozilla's server-side TLS guidelines (version 6.0, available through its configuration generator) are a good baseline. Their "intermediate" profile allows TLS 1.2 and 1.3; for TLS 1.2 it permits only six suites, all ECDHE with AES-GCM or ChaCha20-Poly1305; and it offers the X25519MLKEM768, X25519, P-256 and P-384 groups. In nginx, that looks like this:

ssl_protocols TLSv1.2 TLSv1.3;

# Key-exchange groups; X25519MLKEM768 needs nginx built with OpenSSL 3.5 or later
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;

# TLS 1.2 suites only; TLS 1.3 suites stay at OpenSSL's defaults
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

# Every suite above is strong, so let the client choose
ssl_prefer_server_ciphers off;

If your site sits behind a CDN or cloud load balancer, the client-facing handshake happens there, so choose the equivalent security policy in its settings rather than in nginx. And if every client you serve supports TLS 1.3, Mozilla's "modern" profile drops TLS 1.2 altogether; our comparison of TLS 1.2 vs 1.3 helps you decide when that's safe.

Testing your server

Check what your server actually does, not what the config file says. Three commands cover most of it:

# What does a current client negotiate?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher is|group"

# Is RSA key exchange refused? This should fail.
openssl s_client -connect example.com:443 -servername example.com -tls1_2 -cipher AES128-SHA </dev/null

# List every suite the server accepts
nmap --script ssl-enum-ciphers -p 443 example.com

With a recent OpenSSL, the first command prints lines such as "Protocol: TLSv1.3", "Cipher is TLS_AES_256_GCM_SHA384" and "Negotiated TLS1.3 group: X25519MLKEM768"; that last line tells you whether a hybrid post-quantum exchange was used. Free online scanners such as Qualys SSL Labs and the open-source testssl.sh tool give a fuller report. Test every public hostname, not just the homepage: the API, the video delivery domain and the admin panel often sit on different servers with different settings. Re-test after changing CDN or load balancer settings, and after upgrading OpenSSL or nginx.

Key takeaways

• A TLS 1.2 suite name encodes key exchange, authentication, encryption and hash; a TLS 1.3 name only encryption and hash.
  
  
• TLS 1.3 has five suites; the three AES-GCM and ChaCha20 ones cover almost every client.
  
  
• Forward secrecy comes from ECDHE; suites without it, such as TLS_RSA_*, are now forbidden in TLS 1.2.
  
  
• Remove NULL, anonymous, export, RC4, 3DES, DHE and CBC suites.
  
  
• When every allowed suite is strong, ordering hardly matters, so let clients choose.
  
  
• Test the live server, and every hostname, after each infrastructure change.
  
  

Frequently asked questions

What is cipher suite in TLS?

A cipher suite in TLS is a named combination of cryptographic algorithms that the client and server agree to use for a connection. In TLS 1.2 it covers key exchange, authentication, bulk encryption and a hash, as in TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. In TLS 1.3 it covers only the encryption algorithm and hash, such as TLS_AES_128_GCM_SHA256, with key exchange and signatures negotiated separately.

What is weak cipher suites?

Weak cipher suites are combinations that no longer protect traffic properly. They include suites with no encryption (NULL), no authentication (anonymous), deliberately short keys (EXPORT), broken ciphers (RC4, DES, 3DES), no forward secrecy (TLS_RSA and static ECDH) and CBC-mode designs prone to padding attacks. Security scanners flag them, and servers should disable them, keeping only ECDHE suites with AES-GCM or ChaCha20-Poly1305.

What is cipher suite order?

Cipher suite order is the preference ranking that decides which suite is chosen when client and server share several. The client lists its suites in order; the server either follows the client's order or imposes its own. When every enabled suite is strong, letting the client choose is fine and helps phones pick ChaCha20. Server-side ordering only matters if weaker suites remain enabled, which they shouldn't.