Your server sends a list of cipher suites every time a browser connects. One wrong entry lets attackers downgrade your encryption. Here is how to read the list and configure it correctly in 2026.
Your server sends a list of cipher suites every time a browser connects. One wrong entry lets attackers downgrade your encryption. In 2026, with TLS 1.3 at 75% adoption and post-quantum key exchange rolling out on top of it, getting this list right matters more than ever.
A cipher suite is a named bundle of algorithms that TLS uses for a single connection. The name tells you exactly which key exchange, authentication, encryption, and MAC algorithms will be used. Reading the name is a skill, and it is the first thing a security auditor checks.
The TLS Cipher Suite Lookup tool lets you search and filter cipher suites by IANA name, OpenSSL name, or algorithm to see security ratings and protocol support.
In TLS 1.2, a cipher suite name encodes four components. Take TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:
1. Key exchange (ECDHE): Elliptic Curve Diffie-Hellman Ephemeral. The client and server derive a shared secret using elliptic curve cryptography. "Ephemeral" means a new key pair is generated for each connection, providing forward secrecy. If the server's long-term private key is compromised later, past sessions remain secure.
2. Authentication (RSA): The server proves its identity using an RSA certificate. This is the algorithm that signed the certificate, not the key exchange algorithm. ECDSA certificates are also common.
3. Encryption (AES_128_GCM): AES with a 128-bit key in Galois/Counter Mode. GCM provides both encryption and authentication in a single AEAD operation. Older suites used AES_128_CBC, which requires a separate MAC and is vulnerable to padding oracle attacks (Lucky 13, POODLE variants).
4. MAC (SHA256): SHA-256 is used for the HMAC-based key derivation function and handshake MAC. In AEAD suites like GCM, the MAC algorithm is not used for record-level authentication (GCM handles that), but it is used in the key schedule.
The IANA cipher suite registry lists all registered suites. OpenSSL uses different names (e.g., ECDHE-RSA-AES128-GCM-SHA256 with hyphens instead of underscores), which causes endless confusion. The ciphersuite.info site maps between the two naming conventions.
TLS 1.3 fundamentally changed how cipher suites work. The original specification was RFC 8446 (August 2018). In July 2026, the IETF published RFC 9846, which obsoletes RFC 8446 and tightens several requirements. The cipher suite list is unchanged, but the protocol now forbids negotiating TLS 1.0 and 1.1, mandates key updates before exceeding key usage limits, and uses more generic language for key exchange to accommodate post-quantum KEM algorithms.
TLS 1.2: The client and server negotiate a cipher suite from a long list. The suite includes key exchange, authentication, encryption, and MAC. There are over 300 registered TLS 1.2 cipher suites, including many weak ones (RC4, 3DES, NULL, anonymous DH). A misconfigured server can offer weak suites, and a downgrade attack can force the client to accept one.
TLS 1.3: The cipher suite only specifies the AEAD encryption algorithm and the hash for key derivation. Key exchange and authentication are negotiated separately via extensions. There are exactly five cipher suites:
``
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256
``
All five are AEAD. There is no CBC, no RC4, no NULL, no non-authenticated option. Forward secrecy is mandatory because static RSA and DH key exchange were removed. The protocol simply does not offer the weak options that TLS 1.2 allowed.
RFC 9852, published in July 2026, goes further: it mandates that new protocols using TLS MUST require TLS 1.3. The TLS Working Group has frozen TLS 1.2 development, meaning no new features or improvements will be added to 1.2.
Enable for TLS 1.3: All five TLS 1.3 suites are safe. You cannot configure the TLS 1.3 suite list in most servers (Nginx, Apache, HAProxy do not expose it). The server offers all five and the client picks one. This is by design.
Enable for TLS 1.2 fallback: Only three families:
``
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
``
All provide forward secrecy (ECDHE) and authenticated encryption (GCM or Poly1305). The RSA and ECDSA variants depend on your certificate type.
Disable: RC4 (RFC 7465), 3DES (deprecated by NIST, Sweet32 attack), NULL encryption, anonymous DH, static RSA key exchange (no forward secrecy), CBC mode with SHA-1 (Lucky 13 attack), and any suite with EXPORT in the name (FREAK attack).
Nginx configuration:
``
ssl_protocols TLSv1.2 TLSv1.3;
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;
ssl_prefer_server_ciphers off;
``
Apache configuration:
``
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite 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
``
The Mozilla SSL Configuration Generator produces these settings for your specific server version. Always verify with the SSL Labs test after applying changes.
Server hardening: The most common audit finding is a server still offering TLS 1.0 or CBC cipher suites. As of 2026, PCI DSS bans TLS 1.0, NIST SP 800-52 Rev. 2 requires TLS 1.3 support, and all major browsers block TLS 1.0 and 1.1. A server offering weak suites will receive a B or C grade from SSL Labs even if TLS 1.3 is enabled, because the downgrade path exists.
Post-quantum readiness: TLS 1.3 is the only protocol that supports hybrid post-quantum key exchange. Chrome ships x25519+ML-KEM (the NIST-standardized Kyber) by default, and Cloudflare reports a significant share of its TLS 1.3 traffic already negotiating post-quantum keys. OpenSSL 3.5 brought server-side support. TLS 1.2 cannot be retrofitted for post-quantum algorithms, which is becoming the strongest argument for completing TLS 1.3 rollout.
API and microservice security: Internal service-to-service TLS (mTLS) often uses self-signed certificates and older configurations. The same cipher suite rules apply. Service meshes like Istio and Linkerd negotiate TLS 1.3 by default, but legacy service-to-service connections may still use TLS 1.2 with CBC suites. Audit these with the same rigor as external endpoints.
Embedded and IoT devices: Devices running older OpenSSL or mbedTLS versions may only support TLS 1.2 with a limited suite list. The minimum acceptable configuration is ECDHE with AES-GCM. Devices that only support RSA key exchange or CBC mode should be flagged for firmware updates.
Cipher suite configuration is a snapshot, not a permanent state. New attacks are discovered, algorithms are deprecated, and standards evolve. A configuration that scored A+ in 2020 might score B in 2026 because 3DES was deprecated or because TLS 1.2 CBC suites are now considered legacy.
The block cipher tool demonstrates the difference between AES-GCM and AES-CBC. CBC mode is vulnerable to padding oracle attacks when the implementation leaks whether padding is valid. GCM mode avoids this entirely by using AEAD. The difference is not theoretical: the Lucky 13 attack (2013) showed that TLS 1.2 CBC implementations could be attacked in practice, and the POODLE attack (2014) showed that SSL 3.0 CBC was broken.
TLS 1.3 removed the configuration footgun by offering only AEAD suites. But TLS 1.2 fallback remains necessary for legacy clients, and its configuration must be maintained. The RC4 cipher is a reminder of what happens when weak cipher suites linger in configuration defaults for too long.
A TLS cipher suite is a named set of cryptographic algorithms that TLS uses for a connection. In TLS 1.2, it includes key exchange, authentication, encryption, and MAC algorithms. In TLS 1.3, it includes only the AEAD encryption algorithm and the hash for key derivation, because key exchange and authentication are negotiated separately.
TLS 1.3 has exactly five cipher suites, all AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, and TLS_AES_128_CCM_8_SHA256. There are no CBC, RC4, or NULL options. The protocol does not offer weak algorithms.
Not yet. TLS 1.2 with modern cipher suites (ECDHE with AES-GCM or ChaCha20-Poly1305) is still secure and compliant with PCI DSS and NIST SP 800-52 Rev. 2. Keep TLS 1.3 preferred with TLS 1.2 as a fallback for legacy clients. Disable TLS 1.0 and 1.1, which are formally deprecated by RFC 8996.
Disable all RC4 suites (RFC 7465), 3DES suites (deprecated by NIST, vulnerable to Sweet32), NULL encryption suites, anonymous DH suites, static RSA key exchange suites (no forward secrecy), CBC suites with SHA-1 (Lucky 13 attack), and any EXPORT suites (FREAK attack). Only enable ECDHE suites with AES-GCM or ChaCha20-Poly1305.
IANA names use underscores (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256). OpenSSL names use hyphens (ECDHE-RSA-AES128-GCM-SHA256) and drop the TLS_ prefix and WITH separator. The algorithms are identical. The ciphersuite.info site maps between the two conventions.
TLS Cipher Suite Lookup
Search and filter TLS cipher suites by IANA name, OpenSSL name, hex code, or algorithm. See security ratings, forward secrecy, and protocol support.
Block Cipher (AES / DES)
Encrypt and decrypt with AES-128, AES-256, DES, and Triple DES using GCM, CBC, and ECB modes. AES uses the Web Crypto API.
RC4 Stream Cipher
Encrypt and decrypt data with the RC4 stream cipher using a variable-length key. For education and legacy analysis only.
The Difference Between Encoding, Encryption, and Hashing
Base64 is not encryption. This guide defines encoding, encryption, and hashing precisely, runs the same input through each, and explains when to use which in production systems.
Stream Ciphers vs. Block Ciphers: What's the Difference?
A block cipher encrypts in fixed-size chunks. A stream cipher encrypts one byte at a time. The difference changes everything from padding to nonce reuse. Here is how they compare.
The Rise and Fall of RC4: How the Web's Most Used Cipher Was Broken
RC4 was the most used cipher on the internet in 2013. By 2015 it was banned in TLS. By 2026 Microsoft is removing it from Kerberos. Here is how RC4 worked and why it fell.
