How do you read a cipher suite name?

In TLS 1.2, a cipher suite name like `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` spells out the algorithms in order: TLS (protocol), ECDHE (key exchange), RSA (authentication), AES_128_GCM (bulk encryption), and SHA256 (message authentication/MAC). In TLS 1.3, the names are shorter (e.g., `TLS_AES_128_GCM_SHA256`) because key exchange and authentication are negotiated separately.

How are cipher suites chosen during a connection?

During the initial TLS Handshake, the client sends a list of all the cipher suites it supports, ordered by preference. The server compares this list to its own supported suites and selects the strongest mutually supported cipher suite to use for the session.

Why do some cipher suites become deprecated?

Cipher suites are deprecated when cryptographic researchers discover vulnerabilities in one of their underlying algorithms. For example, suites using RC4 encryption, MD5 hashing, or CBC mode with block ciphers are now considered insecure and have been disabled in modern browsers.

What are the most secure cipher suites to use today?

The most secure suites are those defined in TLS 1.3, specifically `TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, and `TLS_CHACHA20_POLY1305_SHA256`. These use Authenticated Encryption with Associated Data (AEAD), which securely bundles encryption and integrity checking into a single operation.

What happens if the client and server share no cipher suites?

If the client and server cannot agree on a single shared cipher suite (for example, an extremely old browser trying to connect to a modern TLS 1.3-only server), the TLS handshake fails immediately. The connection is aborted, and the user receives a secure connection error.

What Is a Cipher Suite

Q: What is a cipher suite?

A cipher suite is a standardized set of cryptographic algorithms that provide the necessary security components for a network connection. It defines the specific algorithms used for key exchange, digital signatures, bulk encryption, and message authentication during a TLS/SSL session.

Introduction

When you connect to a secure website, your browser and the web server perform a complex cryptographic dance known as the TLS handshake. Within milliseconds, they must agree on how to secretly exchange keys, how to verify each other’s identity, and how to encrypt the actual web page data. But there is no single “internet encryption algorithm.” Different devices support different mathematical formulas, and older devices need to talk to newer servers. To solve this, the TLS protocol uses a cipher suite. A cipher suite is a standardized menu package that bundles all the necessary cryptographic algorithms together into a single, named set. If you manage a web server, configure an API gateway, or run a load balancer, your choice of which cipher suites to support determines whether your traffic is mathematically secure or vulnerable to interception.

What Is a Cipher Suite?

A cipher suite is a named combination of authentication, encryption, and message authentication code (MAC) algorithms used to negotiate the security settings for a network connection using the TLS/SSL protocol.

Because cryptography requires multiple different tools to achieve full security, you cannot use just one algorithm. You need one tool to prove identity (authentication), another tool to agree on a shared secret without anyone eavesdropping (key exchange), another tool to encrypt the data stream (bulk encryption), and a final tool to prove the data hasn’t been tampered with (integrity).

A cipher suite pre-packages these four components. By grouping them into a standardized suite, clients and servers can rapidly communicate their cryptographic capabilities during the initial connection setup.

How to Read a Cipher Suite Name

Cipher suites follow a strict naming convention set by the Internet Assigned Numbers Authority (IANA). The naming convention changed significantly between TLS 1.2 and TLS 1.3, reflecting a shift toward simpler, more secure cryptography.

The TLS 1.2 Convention

A typical TLS 1.2 cipher suite looks like this: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

If you break it apart by its underscores, it spells out the four cryptographic jobs:

Protocol: TLS (Transport Layer Security)
Key Exchange: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral). This is how the two parties agree on a secret session key without transmitting it. The “E” ensures ephemeral keys are used for perfect forward secrecy.
Authentication: RSA. This is the algorithm the server uses alongside its digital certificate to prove its identity.
Bulk Encryption: AES_128_GCM. This is the symmetric cipher that actually encrypts the web traffic. It uses the Advanced Encryption Standard with a 128-bit key in Galois/Counter Mode.
Message Authentication (MAC): SHA256. This hash function ensures the encrypted data is not tampered with in transit.

The TLS 1.3 Convention

TLS 1.3 drastically simplified the protocol. It removed insecure legacy algorithms and separated authentication and key exchange from the cipher suite definition. A typical TLS 1.3 cipher suite looks like this: TLS_AES_128_GCM_SHA256

Notice what is missing: the key exchange (ECDHE) and authentication (RSA) algorithms. In TLS 1.3, those are negotiated separately. The cipher suite now only defines the bulk encryption (AES_128_GCM) and the hash used for the key derivation function (SHA256).

Deconstructing a cipher suite. Each segment of the standardized name defines the specific mathematical algorithm that will handle one of the four required cryptographic tasks for the connection.

This video walks through exactly how a cipher suite string is constructed and how the client and server negotiate which suite to use during the TLS handshake.

How the Negotiation Works

When a client (like your browser) wants to connect to a server, it sends a ClientHello message. Included in this message is a list of every cipher suite the browser supports, ordered from its most preferred (strongest) to least preferred (weakest).

The server receives this list and compares it to the cipher suites it has been configured to support. The server selects the strongest cipher suite that appears on both lists and replies with a ServerHello message containing the chosen suite.

If the server and client share absolutely no common cipher suites (for example, a modern TLS 1.3-only server talking to a 15-year-old browser), the server terminates the connection immediately. This is known as a handshake failure.

Real-World Use Cases

Load Balancer and CDN Configuration: If you configure a load balancer (like AWS ALB or HAProxy) or a CDN (like Cloudflare), you must choose a TLS Security Policy. This policy is simply a predefined list of allowed cipher suites. Choosing a “Modern” policy drops support for TLS 1.2 and only enables TLS 1.3 suites. This provides maximum security and performance (saving CPU cycles on the load balancer) but will block traffic from older Android devices and legacy IoT hardware that only understand older cipher suites.

Microservice Architecture: Inside modern cloud deployments, individual microservices often communicate via mutual TLS (mTLS). In these environments, administrators typically lock down cipher suites to a very restrictive list of just TLS 1.3 AEAD ciphers. Because internal traffic doesn’t need to support legacy web browsers, there is no need to maintain backward compatibility, allowing for maximum security and reduced CPU overhead.

Compliance Audits: Security frameworks like PCI-DSS (for credit card processing) and HIPAA mandate strong cryptography. During an audit, automated scanners will test your web server to see which cipher suites it accepts. If your server accepts a deprecated cipher suite — such as anything using RC4 encryption, MD5 hashing, or 3DES — you will fail the compliance audit immediately.

Common Mistakes to Avoid

Supporting CBC Mode Cipher Suites. Older cipher suites used block ciphers in Cipher Block Chaining (CBC) mode. CBC mode has been devastated by a series of cryptographic attacks over the last decade, including the famous POODLE and Padding Oracle attacks. You must disable all CBC cipher suites and only support suites that use AEAD (Authenticated Encryption with Associated Data), such as AES-GCM or ChaCha20-Poly1305.

Failing to enable Perfect Forward Secrecy (PFS). In older key exchange algorithms (like standard RSA key exchange), if an attacker recorded years of encrypted traffic and later stole the server’s private key, they could decrypt all the historical traffic. Modern best practice requires Perfect Forward Secrecy. You must prioritize cipher suites that use Ephemeral Diffie-Hellman (DHE or ECDHE) for key exchange. With PFS, fresh, temporary keys are generated for every single session. Even if the server’s private key is stolen, past sessions cannot be decrypted.

Getting Started

You do not need to be a cryptographer to configure a secure web server. You should rely on industry-standard configuration generators.

If you are setting up an Nginx, Apache, or HAProxy server, use the Mozilla SSL Configuration Generator. You input your server software version and select the “Intermediate” or “Modern” profile. The generator will output the exact block of configuration code you need to paste into your server, specifying the exact cipher suites to enable and the insecure ones to disable.

Always test your configuration after deploying. Use the Qualys SSL Labs Server Test. This free tool will scan your public URL, test every single cipher suite your server accepts, and give you a grade from A+ to F. It will specifically flag if you are supporting weak ciphers, lacking forward secrecy, or vulnerable to known cryptographic attacks. To dive deeper into the encryption algorithm that dominates modern cipher suites, read our guide on AES-256-GCM Authenticated Encryption.