Cipher Suites Explained

When your browser connects to a website, before any data flows, both sides must agree on the rules. Which algorithms will protect this conversation? How will we prove who we are? How will we keep secrets? The answer to all of these is encoded in a single choice: the cipher suite.

Every cipher suite name is a contract written in acronyms—a binding agreement about how two strangers will protect their conversation.

What a Cipher Suite Actually Specifies

A cipher suite defines four things:

1. Key exchange: How do we agree on a shared secret without anyone eavesdropping being able to figure it out?
2. Authentication: How does the server prove it's really who it claims to be?
3. Encryption: How do we scramble the actual data so only we can read it?
4. Integrity: How do we know the data wasn't tampered with in transit?

Each component uses a specific algorithm. The combination must work together. The cipher suite name tells you exactly which algorithms fill each role.

Reading a Cipher Suite Name

Cipher suite names look intimidating, but they're just a recipe:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Breaking this down:

• ECDHE: Key exchange using Elliptic Curve Diffie-Hellman, ephemeral keys
• RSA: Server proves identity using an RSA certificate
• AES_128_GCM: Data encrypted with AES (128-bit key) in Galois/Counter Mode
• SHA256: Hash function for various protocol operations

TLS 1.3 simplified this dramatically:

TLS_AES_256_GCM_SHA384

Why shorter? TLS 1.3 always uses ephemeral Diffie-Hellman and handles authentication separately. The cipher suite only needs to specify encryption and hashing.

Key Exchange: The Most Critical Choice

Key exchange determines whether your connection has Perfect Forward Secrecy—whether today's conversation stays secret even if the server's private key is stolen tomorrow.

ECDHE is the modern standard. The "E" stands for ephemeral: fresh keys generated for each connection, then destroyed. If someone records your encrypted traffic and later steals the server's private key, they still can't decrypt what they recorded. The keys that protected that conversation no longer exist.

RSA key exchange (without the E) was the old way. The client encrypts a secret using the server's public key. Simple, but dangerous: if that private key is ever compromised, every past conversation encrypted with it becomes readable. This is why RSA key exchange was removed from TLS 1.3 entirely.

The difference between ECDHE and RSA key exchange is the difference between burning your notes after each meeting versus keeping them in a safe that might someday be cracked.

Authentication: Proving Identity

RSA signatures remain common—the server's certificate contains an RSA public key, and the server proves it holds the private key by signing messages.

ECDSA uses elliptic curves for signatures. Equivalent security, smaller keys, better performance. Increasingly popular, but requires an ECDSA certificate.

In TLS 1.3, authentication happens separately from the cipher suite, which is why you don't see RSA or ECDSA in TLS 1.3 cipher suite names.

Encryption: What Actually Protects Your Data

Once the handshake completes, bulk encryption protects every byte of application data. This is where performance matters—these algorithms process everything you send and receive.

AES-GCM is the workhorse. AES is battle-tested, and GCM mode provides both encryption and authentication in a single operation. Most modern processors include hardware acceleration for AES, making it extremely fast.

ChaCha20-Poly1305 is the alternative. Designed by Daniel Bernstein, it's optimized for software performance. On devices without AES hardware acceleration—many mobile phones—ChaCha20 often outperforms AES. TLS 1.3 includes it as a first-class option.

CBC mode was the traditional approach before authenticated encryption. It's been vulnerable to attacks (BEAST, Lucky 13) that required complex mitigations. Still supported in TLS 1.2 for legacy reasons, but deprecated.

3DES and RC4 are broken. If you see either in a cipher suite, something is very wrong.

The TLS 1.3 Simplification

TLS 1.2 offered dozens of cipher suites, many of them insecure. Administrators had to know which to enable and which to disable. Most got it wrong.

TLS 1.3 offers 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

The last two are for constrained IoT environments. Most servers enable just the first three.

This wasn't just simplification—it was the protocol designers admitting that giving people choices they couldn't evaluate was making everyone less secure. When every option is a good option, you can't choose wrong.

Configuring TLS 1.2 Securely

If you still support TLS 1.2 for legacy clients, a secure configuration looks like:

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

Notice the pattern: all use ECDHE (Perfect Forward Secrecy), all use authenticated encryption (GCM or Poly1305), none use deprecated algorithms.

Disable everything else. RSA key exchange, CBC mode, 3DES, RC4, MD5, SHA-1—all of them.

How Cipher Suites Get Chosen

During the TLS handshake, the client sends a list of cipher suites it supports, ordered by preference. The server picks one.

Modern best practice: configure the server to choose based on its own preferences, not blindly accept the client's first offer. The server knows its hardware capabilities—whether it has AES acceleration, what its performance characteristics are. Let it optimize.

Checking Your Connection

Your browser's developer tools (Security tab) show the negotiated cipher suite for any connection. Online tools like SSL Labs' Server Test evaluate a server's entire cipher suite configuration, identifying weaknesses.

If you see RSA key exchange, CBC mode, 3DES, or SHA-1 in active use—the server needs attention.