An Introduction to Cipher Suites

Published: January 2025. Updated: August 2026. Reviewed by Encryption Consulting’s Cryptography advisory team.

As consultants in the field of applied cryptography, we often encounter the question of whether enabling encryption is enough to ensure the security of digital communication. It is not, because encryption is only as strong as the algorithms a connection actually negotiates, and that negotiation is exactly what a cipher suite governs.

When a message is sent across a connection, a TLS/SSL connection is normally used to encrypt the data in that message. Establishing this connection requires a TLS handshake, and inside that handshake the client and server exchange the cipher suites each side supports so they can settle on a common set of algorithms before any application data is sent.

What Is a Cipher Suite?

A cipher suite is a named, standardized combination of cryptographic algorithms that a TLS client and server agree to use for a given connection. It determines how the connection creates and exchanges keys, how each side proves its identity, how the bulk of the data gets encrypted, and how the integrity of that data is checked. Two entities that pick different algorithms for any of these jobs cannot understand each other, so the cipher suite is the contract both sides sign before any data moves.

The Four Components of a Cipher Suite

1. Key exchange algorithm. Establishing a secure channel requires both sides to arrive at the same symmetric session key without ever sending it in the clear. The key exchange algorithm is how that key gets negotiated. RSA, DH, ECDH, and ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) are the common choices; ECDHE is preferred today because it provides forward secrecy, a property covered in depth in our companion article on Perfect Forward Secrecy.
2. Authentication algorithm. This is how the server (and optionally the client) proves its identity, typically by signing part of the handshake with the private key tied to its certificate. RSA, DSA, and ECDSA are the common authentication algorithms, and the certificate installed on the server must use a key type that matches the algorithm the negotiated suite expects.
3. Bulk data encryption algorithm. This is the cipher that encrypts the actual message content once the handshake completes, so it needs to be both fast and hard to break. AES is the dominant choice today; 3DES and RC4 were common historically but are now deprecated.
4. MAC or AEAD algorithm. Encryption alone does not guarantee that a message was not tampered with in transit. Older suites paired a separate Message Authentication Code (MAC), often HMAC built on SHA-2, with the bulk cipher. Modern suites instead use an AEAD (Authenticated Encryption with Associated Data) cipher such as AES-GCM or ChaCha20-Poly1305, which performs encryption and integrity checking as a single operation and removes an entire class of implementation bugs that separate encrypt-then-MAC designs were prone to.

A TLS 1.2 cipher suite name spells out all four pieces, for example TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: ECDHE is the key exchange, RSA is the authentication algorithm, AES_256_GCM is the AEAD bulk cipher, and SHA384 is the hash used inside the AEAD construction. TLS 1.3 cipher suite names are shorter because the key exchange and authentication algorithms are no longer part of the name at all; they are negotiated separately through other parts of the handshake. That is why a TLS 1.3 suite name like TLS_AES_256_GCM_SHA384 only lists the AEAD cipher and hash.

How Does a TLS Handshake Negotiate a Cipher Suite?

Direct answer: The client sends the cipher suites it supports in order of preference, the server picks the strongest one it also supports, and the rest of the handshake proceeds using only the algorithms named in that suite. The exact number of round trips depends on the TLS version.

1. Client Hello. The client sends the TLS versions it supports, an ordered list of cipher suites, a random value (the “client random”), and, in TLS 1.3, a set of tentative key shares.
2. Server Hello and cipher suite selection. The server picks a TLS version and a single cipher suite from the client’s list, generates its own random value (the “server random”), and, in TLS 1.3, returns a matching key share so both sides can derive handshake keys immediately.
3. Certificate and authentication. The server sends its certificate and proves possession of the corresponding private key using the authentication algorithm the negotiated suite requires. The client validates that certificate through its certificate authority chain.
4. Key establishment. In TLS 1.2, the client encrypts or derives a pre-master secret using the negotiated key exchange algorithm and sends what the exchange requires back to the server. In TLS 1.3, both sides instead combine the key shares already exchanged in steps 1 and 2, which is what lets TLS 1.3 finish in one round trip instead of two.
5. Session key derivation. Both sides independently derive the same symmetric session keys from the shared secret and the random values exchanged earlier, using the hash function named in the cipher suite.
6. Finished messages. Each side sends a Finished message authenticated with the newly derived keys. If both sides can verify each other’s Finished message, the handshake is complete and every subsequent record is protected with the bulk encryption and MAC/AEAD algorithms the negotiated cipher suite specifies.

Which Cipher Suites Should You Use for TLS 1.3?

Direct answer: Use the three AEAD suites RFC 8446 defines for general-purpose use: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, and TLS_CHACHA20_POLY1305_SHA256. There is no configuration decision to make beyond which of these three to prioritize, because TLS 1.3 removed every non-AEAD, non-forward-secret option from the protocol.

RFC 8446 restricts TLS 1.3 to AEAD ciphers only and drops CBC-mode, RC4, and static RSA key exchange entirely; every TLS 1.3 handshake is forward secret by construction. Two additional AEAD suites, TLS_AES_128_CCM_SHA256 and TLS_AES_128_CCM_8_SHA256, exist for constrained environments such as embedded and IoT devices where GCM’s implementation cost is harder to justify, but they are rarely the right choice for a general-purpose web server.

Which Cipher Suites Should You Use for TLS 1.2?

Direct answer: Restrict TLS 1.2 to ECDHE-based AEAD suites, and only add DHE-based fallbacks if you have a documented compatibility need. Do not enable static RSA, static DH, RC4, 3DES, or CBC-mode suites unless a specific legacy client leaves you no alternative.

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (Recommended, needs an ECDSA certificate)
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Recommended, needs an RSA certificate)
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Recommended, needs an ECDSA certificate)
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Recommended, needs an RSA certificate)
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (Recommended, needs an ECDSA certificate)
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Recommended, needs an RSA certificate)
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (Broader-compatibility fallback only)
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Broader-compatibility fallback only)
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (Weak: CBC mode, avoid unless required for legacy clients)
• TLS_RSA_WITH_AES_256_CBC_SHA (Weak: no forward secrecy, static RSA key exchange, avoid)

Why Are Some Cipher Suites Considered Weak or Deprecated?

Direct answer: RC4, 3DES, export-grade ciphers, and CBC-mode suites each have documented, practical attacks against them. Cipher suites built on any of these should be disabled rather than deprioritized.

• RC4. Statistical biases in the RC4 keystream allow an attacker who observes enough traffic to recover plaintext. RFC 7465 formally prohibits negotiating RC4 cipher suites in TLS.
• 3DES. 3DES uses a 64-bit block size, which makes it vulnerable to the Sweet32 birthday-bound collision attack (CVE-2016-2183) once a connection encrypts enough data under one key. It should be treated as deprecated even though it is not broken in the same way RC4 is.
• Export ciphers. Suites deliberately weakened to comply with 1990s export controls (identifiable by “_EXPORT_” in the name) use key sizes short enough to brute-force today. They have no legitimate use in modern deployments.
• CBC-mode padding oracle attacks. CBC-mode ciphers pad plaintext to a block boundary, and if a server’s error handling reveals whether that padding was valid, an attacker can decrypt traffic one byte at a time without ever knowing the key. Lucky 13 and POODLE are the best-known examples of this class of attack against TLS’s CBC-mode suites, which is why AEAD ciphers that do not need padding are now preferred over MAC-then-encrypt CBC constructions.

Performance and Interoperability Trade-Offs

Direct answer: On modern server and client hardware, AES-GCM is the fastest option because of AES-NI hardware acceleration; on hardware without that acceleration, ChaCha20-Poly1305 performs better in software. Interoperability, not raw speed, is usually what forces a broader cipher suite list.

AES-NI is a set of CPU instructions, available on effectively all modern server, desktop, and mobile processors, that perform AES rounds directly in hardware. Where AES-NI is present, AES-GCM encryption and decryption are essentially free from a CPU-cycle standpoint. Where it is absent, such as on some older or lower-power mobile chips, computing AES in software is comparatively expensive, and ChaCha20-Poly1305 (designed from the start to run efficiently without dedicated hardware) closes that gap and is why browsers like Chrome prioritize it for mobile clients.

The harder trade-off is usually compatibility. A cipher suite list restricted to ECDHE-AEAD suites is the right default, but it will fail to connect to genuinely old clients (older enterprise middleware, some embedded devices, or unpatched legacy browsers) that only speak CBC-mode or DHE-only suites. Before adding a broader-compatibility fallback, confirm with server logs or a monitoring tool which specific clients actually need it, and scope the exception as narrowly as possible rather than reopening the full legacy list.

Recommended Cipher Suites by Scenario

Scenario	TLS versions	Cipher suites	Notes
Modern-only (internal APIs, service-to-service, latest browsers/clients)	TLS 1.3 only	TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256	Simplest and fastest configuration; no CBC or RSA key exchange exposure at all.
Broad public-facing compatibility (customer-facing web, must support somewhat older clients)	TLS 1.2 and TLS 1.3	TLS 1.3 AEAD suites above, plus TLS_ECDHE_ECDSA/RSA_WITH_AES_128/256_GCM and TLS_ECDHE_ECDSA/RSA_WITH_CHACHA20_POLY1305_SHA256	Matches Mozilla’s “intermediate” guidance; forward secret on every suite offered.
Legacy interoperability (specific enterprise clients that cannot be upgraded)	TLS 1.2 minimum, scoped exception	Add TLS_DHE_RSA_WITH_AES_128/256_GCM_SHA256/384 only for the specific client that needs it	Treat as a temporary, documented exception, not a default; avoid CBC-mode and RC4/3DES entirely.

How Does Cipher Suite Choice Depend on Certificate Key Type (RSA vs ECDSA)?

Direct answer: A server can only offer the ECDSA cipher suites in its list if its certificate uses an ECDSA key, and can only offer the RSA cipher suites if its certificate uses an RSA key. Cipher suite selection is not independent of certificate management; the two decisions have to be made together.

A suite named TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 requires the server to authenticate with an ECDSA certificate; TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 requires an RSA certificate for that same handshake step. This is why organizations that want both the smaller key sizes and faster signing ECDSA offers, and the broadest possible client compatibility RSA still guarantees, deploy dual certificates (one RSA, one ECDSA) on the same server and let the server’s TLS stack pick whichever certificate matches the cipher suite the client negotiated. Getting this wrong, such as issuing only an ECDSA certificate on a server whose client base cannot negotiate ECDSA suites, silently locks out clients that would otherwise connect. Planning certificate issuance and cipher suite policy together is a core part of a well-run PKI program.

Limitations

Choosing the right cipher suites reduces risk, but it does not solve every TLS security problem on its own. A correctly configured suite list cannot compensate for a compromised private key, a misissued certificate, or a client that ignores certificate validation errors. Cipher suite selection also only controls the algorithms available to negotiate; it cannot force a client that does not offer strong suites to use them; a client stuck on TLS 1.0 with only CBC-mode suites will either fail to connect or force the server to fall back, depending on policy. Finally, cipher suite hardening does not by itself deliver forward secrecy guarantees beyond what the negotiated key exchange provides. Static RSA key exchange, if still enabled, exposes every past session to a single private key compromise, a risk covered in detail in our Perfect Forward Secrecy article.

What Would Encryption Consulting Recommend?

Our default recommendation is to run TLS 1.3 wherever your client base supports it, since it removes the weak-suite decision entirely, and to configure TLS 1.2 as a compatibility floor restricted to ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. Disable RC4, 3DES, export ciphers, and CBC-mode suites outright rather than deprioritizing them, and re-test your active cipher suite list against your real client population (via server access logs or a TLS scanning tool) at least once a year, since browser and OS defaults shift over time. If your organization issues its own certificates, align certificate key-type strategy (RSA, ECDSA, or both) with the cipher suites you intend to support before rollout, not after. Our Encryption Advisory Services team can run a full encryption assessment against your current TLS configuration, and our encryption audit service can validate that your cipher suite policy is actually enforced in production, not just documented.

Impact of Post-Quantum Cryptography on Cipher Suites

Sufficiently large quantum computers running Shor’s algorithm would break the RSA and ECDSA key exchange and authentication algorithms that current cipher suites rely on, since both depend on integer factorization and discrete-logarithm problems that classical computers find infeasible but quantum computers do not. This is a threat to the key exchange and authentication legs of a cipher suite, not the AEAD bulk cipher itself; AES-256 and ChaCha20-Poly1305 are already considered quantum-resistant at their current key sizes.

NIST has standardized ML-KEM (based on CRYSTALS-Kyber) for key establishment and ML-DSA (based on CRYSTALS-Dilithium), along with FN-DSA (FALCON) and SLH-DSA (SPHINCS+), for digital signatures. The near-term path for TLS is hybrid key exchange, combining a classical algorithm like ECDHE with ML-KEM in the same handshake, so that a connection stays safe even if only one of the two algorithms eventually falls. Deployments handling long-lived, highly sensitive data should start planning for hybrid key exchange now, since data captured today can be decrypted later once a cryptographically relevant quantum computer exists (the “harvest now, decrypt later” risk), even though the bulk-cipher portion of the cipher suite does not need to change.

Conclusion

A cipher suite is what tells a TLS client and server exactly how to encrypt, authenticate, and verify their conversation, and getting that choice right is one of the highest-leverage, lowest-effort changes you can make to a TLS deployment. Run TLS 1.3 where you can, restrict TLS 1.2 to ECDHE-AEAD suites, retire RC4, 3DES, export ciphers, and CBC-mode suites, and make sure your certificate key types actually match the cipher suites you intend to offer. Cipher suites are one layer of a secure connection; proper certificate management, code signing, and secure SSH keys all need to be handled correctly alongside it for a connection to be genuinely secure end to end.

FAQs

What is a cipher suite in simple terms? A cipher suite is the specific combination of algorithms, for key exchange, authentication, bulk encryption, and message integrity, that a client and server agree to use for one TLS connection. It is negotiated automatically at the start of every HTTPS connection.

What are the four components of a TLS cipher suite? Key exchange algorithm (how the session key is established, such as ECDHE), authentication algorithm (how the server proves its identity, such as RSA or ECDSA), bulk encryption algorithm (the cipher that protects the actual data, such as AES), and MAC or AEAD algorithm (the integrity check, such as SHA-384 or the built-in authentication tag in GCM).

Which cipher suites should I enable for TLS 1.3? All three of RFC 8446’s AEAD suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, and TLS_CHACHA20_POLY1305_SHA256. There is no weaker option to accidentally enable in TLS 1.3, since the protocol only defines AEAD suites.

Why is CBC mode considered weak in TLS? CBC-mode ciphers require padding to a block boundary, and TLS implementations have repeatedly leaked whether that padding was valid through timing or error-message differences. Attacks such as Lucky 13 and POODLE exploited exactly that leak to decrypt traffic without recovering the key, which is why AEAD ciphers that avoid padding entirely are now preferred.

Does my choice of cipher suite depend on my certificate’s key type? Yes. ECDSA cipher suites only work if the server presents an ECDSA certificate, and RSA cipher suites only work with an RSA certificate. A server that wants to offer both needs to hold both certificate types and let its TLS stack select the matching one per handshake.

References

• IETF, RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• IETF, RFC 7465: Prohibiting RC4 Cipher Suites
• IANA, TLS Cipher Suites Registry
• Mozilla, SSL Configuration Generator and Server Side TLS guidelines
• Sweet32.info, Birthday Attacks on 64-bit Block Ciphers in TLS and OpenVPN