What Is a Cipher Suite? How It Works in TLS

Every time a browser connects to a website over HTTPS, or a device authenticates to a network, both sides must agree on the rules for how they will protect that exchange.

Those rules are the cipher suite.

Choose a weak one and an attacker may be able to decrypt traffic or impersonate a server. Choose a strong one and the connection is protected even if the long-term private key is later compromised.

This article breaks down what a cipher suite is, explains its four components, walks through how TLS negotiation selects one, and covers the important differences between TLS 1.2 and TLS 1.3 cipher suite models.

What Is a Cipher Suite?

A cipher suite is a combination of cryptographic algorithms that defines how two parties establish and protect a secure communication session. The algorithms within a suite each play a distinct role:

• One negotiates the shared secret.
• One authenticates the parties.
• One encrypts the payload.
• One verifies data integrity.

Every cipher suite has an assigned identifier registered with the Internet Assigned Numbers Authority (IANA) and a human-readable name that encodes which algorithms are combined. The name is not arbitrary. It follows a structured naming convention so any engineer can read the string and immediately know which algorithms are in play.

Cipher suites are used wherever transport layer security (TLS) protects a connection: HTTPS web sessions, Wi-Fi 802.1X authentication, VPN tunnels, and certificate enrollment protocols such as Simple Certificate Enrollment Protocol (SCEP) and the Automated Certificate Management Environment (ACME) protocol.

The Four Components of a Cipher Suite

A TLS 1.2 cipher suite bundles four algorithm roles into a single named package. Understanding each role explains why cipher suite choices matter.

1. Key Exchange Algorithm

The key exchange algorithm lets the client and server establish shared secret material without transmitting the resulting session encryption keys across the network. In some TLS 1.2 key exchange methods, encrypted key material is sent over the network, but an attacker monitoring the connection cannot read the secret in cleartext.

Common key exchange algorithms include:

• RSA (Rivest–Shamir–Adleman): The server’s public key encrypts a pre-master secret that only the server can decrypt. Simple, but does not provide forward secrecy because the same long-term key is used for every session.
• DHE (Diffie-Hellman Ephemeral): Generates a fresh key pair for each session, providing forward secrecy so that compromising the long-term private key does not expose past sessions.
• ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): The elliptic-curve variant of DHE; provides the same forward secrecy at smaller key sizes and lower computational cost.

2. Authentication Algorithm

The authentication algorithm answers the question: is this server who it claims to be?

After key exchange parameters are shared, the server (and optionally the client) must prove its identity with a digital signature that can be verified against a certificate issued by a trusted certificate authority (CA).

Common authentication algorithms:

• RSA: The server signs a piece of data with its private key; the client verifies the signature using the public key in the server’s certificate.
• ECDSA (Elliptic Curve Digital Signature Algorithm): Produces shorter signatures than RSA at equivalent security levels, which reduces handshake overhead.
• DSA (Digital Signature Algorithm): An older standard that is no longer approved for generating new digital signatures under NIST’s current standard and is not supported in TLS 1.3.

3. Bulk Encryption Algorithm

The bulk encryption algorithm encrypts the actual payload data after the session is established. This is the cipher that protects every byte of application data in transit.

• AES (Advanced Encryption Standard): The dominant choice, available in 128-bit and 256-bit key lengths.
• ChaCha20: A stream cipher designed for performance in software, especially on devices without hardware AES acceleration.
• 3DES (Triple Data Encryption Standard): A legacy algorithm now deprecated by modern TLS implementations due to the SWEET32 birthday attack.

Cipher mode also matters.

Galois/Counter Mode (GCM) and ChaCha20-Poly1305 are authenticated encryption with associated data (AEAD) schemes that combine encryption and integrity into one operation, which removes the separate MAC step and closes certain attack surfaces.

4. Message Authentication Code (MAC) Algorithm

The message authentication code (MAC) algorithm verifies that data was not modified in transit. At the end of each record, a hash-based tag proves the ciphertext arrived intact. If a single bit changes, the tag fails verification and the record is rejected.

• HMAC-SHA-256 and HMAC-SHA-384 are the standard choices for TLS 1.2 suites that use a separate MAC.
• In AEAD cipher modes (GCM, ChaCha20-Poly1305), the integrity check is built into the cipher itself, so no separate MAC algorithm appears in the cipher suite name.

How to Read a Cipher Suite String

TLS 1.2 cipher suite names follow a consistent naming pattern that encodes all four components.

Example: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

This table shows what each part of that naming pattern means:

Position	Value	Meaning
Protocol prefix	TLS	Transport Layer Security
Key exchange	ECDHE	Elliptic Curve Diffie-Hellman Ephemeral
Authentication	RSA	RSA digital signature
Separator	WITH	Marks the transition to cipher and hash
Bulk cipher + mode	AES_256_GCM	AES with 256-bit key in GCM mode
Integrity	SHA384	SHA-384 hash for PRF

Reading left to right, you can immediately assess security: ECDHE confirms forward secrecy, AES_256_GCM confirms AEAD encryption, and SHA384 confirms a strong hash function.

A suite such as TLS_RSA_WITH_RC4_128_MD5 would signal static key exchange (no forward secrecy), a broken stream cipher, and a broken hash, all three red flags.

How Cipher Suite Negotiation Works in the TLS Handshake

Cipher suite selection happens in the first messages of the TLS handshake, before any application data flows. The process allows both parties to agree on a cipher suite they support.

TLS 1.2 Handshake (Two Round Trips)

The TLS 1.2 handshake requires two round trips between client and server.

1. ClientHello: The client sends a list of cipher suites it supports, ordered by preference (strongest first), along with the TLS versions it accepts and a random nonce.
2. ServerHello: The server picks one cipher suite from the client’s list and responds with its certificate and the chosen suite identifier.
3. Key exchange messages: Depending on the chosen key exchange algorithm, additional messages carry Diffie-Hellman parameters or allow RSA key encapsulation.
4. Certificate verification: The server (and optionally the client) proves its identity with a digital signature.
5. ChangeCipherSpec and Finished: Both sides send a Finished message, encrypted with the newly negotiated keys, confirming that the handshake completed without tampering.
6. Application data begins: Only after both Finished messages are verified does encrypted application data flow.

If the server cannot find a cipher suite that appears on the client’s list, the handshake fails with a handshake_failure alert and the connection is dropped.

TLS 1.3 Handshake (One Round Trip)

TLS 1.3 reduced the handshake to a single round trip by restructuring how parameters are exchanged.

1. The client sends key share data speculatively in the ClientHello, alongside its cipher suite list.
2. If the server supports one of the proposed groups, it can immediately compute the shared secret and return encrypted data in its first response, cutting the connection setup latency by one round trip compared to TLS 1.2.

Because full TLS 1.3 handshakes use ephemeral key exchange, they provide forward secrecy. TLS 1.3 also supports PSK-based resumption, which can use an ephemeral key exchange for forward secrecy or use PSK-only key establishment without it.

Note: TLS 1.3 also supports 0-RTT early data for resumption for connections. However, 0-RTT data does not provide forward secrecy, so applications should avoid sending sensitive or replay-sensitive data through this mechanism.

TLS 1.2 vs. TLS 1.3 Cipher Suites

TLS 1.3’s most visible change is a much shorter cipher suite list. The table below shows the biggest differences between TLS 1.2 and TLS 1.3:

Feature	TLS 1.2	TLS 1.3
Number of cipher suites	37 in the base spec (hundreds registered with IANA)	5 defined
Algorithms per suite	4 (key exchange, auth, cipher, MAC)	2 (AEAD cipher, hash for HKDF)
Key exchange	Negotiated in cipher suite (including static RSA)	Ephemeral for all full handshakes (PSK-only resumption excepted); key share separate from suite
Forward secrecy	Optional (static RSA widely used)	Provided by all full handshakes; not provided by PSK-only resumption or 0-RTT
Handshake round trips	2-RTT	1-RTT (0-RTT for resumption)
Supported cipher modes	CBC, GCM, CCM, ChaCha20-Poly1305	AEAD only (GCM, CCM, ChaCha20-Poly1305)
Deprecated algorithms removed	Not by the spec — banned later by separate RFCs (RC4, MD5/SHA-1 signatures)	Yes (RC4, 3DES, SHA-1, MD5 removed)

The Five TLS 1.3 Cipher Suites

TLS 1.3 defines exactly five cipher suites, all of them AEAD.

1. TLS_AES_128_GCM_SHA256
2. TLS_AES_256_GCM_SHA384
3. TLS_CHACHA20_POLY1305_SHA256
4. TLS_AES_128_CCM_SHA256
5. TLS_AES_128_CCM_8_SHA256

Notice the naming format changed. A TLS 1.3 suite name contains only the AEAD algorithm and the hash function used with HKDF (the key derivation function). Key exchange and authentication algorithms are negotiated separately in the handshake extensions, which is why they no longer appear in the suite name.

Why the Simplification Matters

The long TLS 1.2 cipher suite list existed partly for backward compatibility and partly because no single suite was universally available across all clients and servers in the early TLS era.

The downside was that administrators had to choose which suites to enable, weak suites often remained active by default, and the complexity of negotiation opened doors to downgrade attacks where an attacker coerced both sides into choosing a weaker suite.

TLS 1.3 addressed this by removing the negotiation of key exchange algorithms from the cipher suite itself, removing static RSA key exchange and requiring ephemeral key exchange for full handshakes, eliminating several legacy algorithms, and reducing the number of configurable parameters that could be misconfigured.

Cipher Suites in Certificate-Based Network Authentication

Cipher suite choices matter beyond web browsing.

In enterprise networks, 802.1X authentication uses Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) to verify device identity before granting access to Wi-Fi or a wired port. EAP-TLS runs a full TLS handshake between the supplicant (the device) and the authentication server, so the cipher suites configured on the RADIUS server directly affect the security of every network connection.

An administrator running a misconfigured RADIUS server that still accepts TLS 1.2 suites with static RSA or CBC-mode ciphers is accepting unnecessary risk. Modern configurations should prefer TLS 1.3 where supported and limit TLS 1.2 suites to ECDHE-based suites with GCM encryption and SHA-256 or stronger hashes.

For context on what happens at the protocol layer during those sessions, see TLS Explained: Why TLS 1.3 Is the New Standard and What Is Port 443?

Weak Cipher Suites and How to Avoid Them

Not all cipher suites are equally secure. Some were once acceptable and are now deprecated. Others were always weak but remained active for compatibility reasons.

Cipher suites to avoid:

• Any suite with NULL: Means no encryption or no authentication. Traffic is plaintext or unauthenticated.
• EXPORT suites: Intentionally weakened key lengths dating to 1990s U.S. export regulations. Exploited by the FREAK and Logjam attacks.
• Suites using RC4: The RC4 stream cipher has cryptographic weaknesses that allow statistical attacks on encrypted data.
• Suites using 3DES: Vulnerable to the SWEET32 birthday attack, particularly in long-lived sessions.
• Suites using MD5 or SHA-1 for the MAC: Both hash functions are broken for collision resistance and should not be used in new deployments.
• Static RSA key exchange (..): No forward secrecy. If the server’s private key is ever compromised, all past sessions can be decrypted.

Note: NIST SP 800-52 Rev. 2 provides specific guidance for federal deployments, requiring TLS 1.2 with FIPS-approved cipher suites and mandating support for TLS 1.3.

Secure Cipher Suite Configuration With JoinNow Dynamic PKI

Correct cipher suite configuration is part of a broader certificate-based authentication strategy. If a network relies on weak cipher suites or outdated TLS versions, the underlying certificates protecting that network provide less assurance than the organization assumes.

JoinNow Dynamic PKI automates certificate lifecycle management for the devices and servers that use those suites. When certificate enrollment uses SCEP or ACME over TLS, the cipher suite on the enrollment endpoint determines how securely the private key and certificate are delivered to each device.

JoinNow Cloud RADIUS enforces certificate-based authentication over EAP-TLS, and aligns its TLS configuration with current IETF and NIST guidance to use strong, forward-secret cipher suites for 802.1X authentication.

Together, these components close the gap between understanding what cipher suites should be configured and having the managed infrastructure to enforce those configurations across every device in the environment.

Schedule a demo to see how SecureW2 can help your organization enforce certificate-based authentication with modern TLS configurations.

---

Frequently Asked Questions

What is a cipher suite in simple terms?

A cipher suite is a set of rules that a client and server both agree to follow when establishing an encrypted connection. The rules specify which algorithm is used to share a secret key, which is used to verify identities, which is used to encrypt the data, and which is used to confirm the data was not changed in transit. You can think of it as a recipe that both sides must have and agree on before they can communicate securely.

How is a cipher suite chosen during the TLS handshake?

The client sends a list of cipher suites it supports, ordered from most preferred to least preferred, in its initial ClientHello message. The server reviews that list and selects a cipher suite that it also supports. If no overlap exists, the handshake fails and the connection is refused. The exact selection policy depends on the server's configuration, so the server does not necessarily choose the client's first preference.

Can I disable weak cipher suites without breaking older clients?

Usually yes, but test before you do. Most current clients support ECDHE with GCM, so removing RC4, 3DES, and static RSA rarely causes problems. The risk is legacy devices or old browsers that only understand outdated suites, since those connections fail once the suites they rely on are gone. Before changing anything in production, review your logs to see which clients still negotiate weak suites, then phase them out rather than cutting them all at once.

Why does forward secrecy matter in a cipher suite?

Forward secrecy means that compromising a server’s long-term private key does not expose past session keys. Each full handshake generates fresh, ephemeral key material that is discarded after use. Without forward secrecy, as with static RSA key exchange, an attacker who records encrypted traffic and later obtains the private key may be able to decrypt it retroactively. Cipher suites using ECDHE or DHE key exchange provide forward secrecy. In TLS 1.3, every full handshake uses ephemeral key exchange and provides forward secrecy, but PSK-only resumption and 0-RTT early data do not.

How do I know which cipher suites my server is offering?

You can inspect a server’s offered cipher suites using command-line tools such as OpenSSL’s s_client subcommand or browser developer tools that display the negotiated suite after a successful TLS handshake. Security scanning tools and online SSL test services also enumerate the full list of suites a server advertises. The negotiated suite for an active session typically appears in the browser’s certificate or security panel under the connection details section.