Cipher Suite

In short: A fixed combination of algorithms (key exchange, encryption, hash function) that a TLS connection uses for its entire duration.

In more detail: A cipher suite such as TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 specifies: which method is used for the key exchange (ECDHE), which algorithm for authentication (RSA), which symmetric algorithm for the actual encryption (AES-256-GCM) and which hash function for integrity checks (SHA-384). In the handshake, the client proposes a list of supported cipher suites, and the server chooses one of them.

In Depth

The name of a cipher suite encodes all four algorithms in a fixed order:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 |     |      |         |         |
 |     |      |         |         +-- hash function for integrity (SHA-384)
 |     |      |         +------------ encryption + mode (AES-256 in GCM mode)
 |     |      +---------------------- authentication/signature (RSA certificate)
 |     +----------------------------- key exchange (ECDHE = elliptic curves, Diffie-Hellman, ephemeral)
 +----------------------------------- protocol (TLS)

The “E” in ECDHE stands for “ephemeral” — a fresh, temporary key pair is generated for every new connection and discarded after the session. This is the core of perfect forward secrecy: even if an attacker later steals the server’s long-term private key, they can’t use it to decrypt connections recorded in the past afterwards, because the actual session keys were never stored long-term.

The negotiation process in the handshake runs like this: in its ClientHello, the client sends a prioritised list of all the cipher suites it supports. The server goes through this list and chooses the first one it also supports itself (or rejects the connection if there’s no match). Outdated, insecure cipher suites (e.g. those with RC4 or without forward secrecy) are deliberately no longer offered at all by modern servers, in order to prevent downgrade attacks in which an attacker tries to force the connection to use a weaker algorithm.

Simplified naming in TLS 1.3

TLS 1.3 radically simplified cipher suite names: because the key exchange (always ECDHE) and authentication (always via the certificate) are no longer part of the cipher suite negotiation but are negotiated separately, only three components remain in the name, e.g. TLS_AES_256_GCM_SHA384 instead of the long TLS 1.2 names. At the same time this drastically reduces the number of possible combinations — TLS 1.3 knows only a handful of cipher suites, all with forward secrecy and without known vulnerabilities, in contrast to the hundreds of historically existing TLS 1.2 combinations, many of which have long been considered insecure.

Well-known downgrade and vulnerability attacks

The history of TLS knows several prominent attacks that deliberately exploited weak cipher suite components: BEAST (2011) exploited a weakness in the CBC encryption mode in TLS 1.0, POODLE (2014) forced connections down to the outdated SSL 3.0 to exploit a similar CBC weakness, and Sweet32 (2016) affected cipher suites with 3DES, whose small 64-bit block size made collisions likely on very long connections. Each of these incidents led browser vendors and server operators to remove the affected cipher suite components (CBC modes, SSL 3.0, 3DES) from their default configurations — today’s comparatively short list of secure cipher suites is the result of a decades-long “thinning-out process”.

Server configuration in practice

Server operators can configure their own cipher suite priority (e.g. in nginx or Apache) and thus control which suite is preferred when the client supports several options. Tools such as Qualys SSL Labs’ “SSL Server Test” automatically check publicly reachable servers for outdated cipher suites and award a rating from A to F — a common first step in securing a new server.

See also: Handshake Protocol, TLS