TLS cipher suites: what they are and how to read them

A cipher suite is a named set of algorithms that a client and a server agree to use for one TLS connection. In TLS 1.2 the name lists all of them: how the keys are exchanged, how the server proves its identity, how data is encrypted and which hash is used. TLS 1.3 shortened the list to five suites that name only encryption and hashing. Both sides choose a suite during the TLS handshake, and it is part of the TLS protocol section.

Quick facts

Chosen

during the handshake: the client offers a list, the server picks one

TLS 1.2 example

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS 1.3 suites

five defined; three enabled by default in OpenSSL

Registry

IANA TLS Cipher Suites

When none match

the handshake fails; see cipher mismatch

What a cipher suite does

A TLS connection needs four jobs done. The two sides must agree on a shared secret without revealing it, the server must prove it holds the certificate's private key, the data must be encrypted, and every record must be protected against changes in transit. A cipher suite settles which algorithm does each job, so the two sides choose one name instead of negotiating four separate choices.

The suite is fixed for the connection. A different connection to the same site, from another client, can use another suite.

How to read a TLS 1.2 suite name

Take TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 apart:

The authentication part has a practical consequence. A suite marked RSA works only with a certificate that has an RSA key, and a suite marked ECDSA only with an ECDSA key. A server whose list allows only ECDSA suites while its certificate has an RSA key cannot complete any TLS 1.2 handshake.

What changed in TLS 1.3

TLS 1.3 removed key exchange and authentication from the suite name. Key exchange is always ephemeral Diffie-Hellman, negotiated separately as a group, and the signature algorithm is negotiated on its own as well. What remains is the encryption algorithm and the hash. RFC 8446 defines five suites:

All five use authenticated encryption, and all the older choices are gone: RC4, 3DES, CBC-mode ciphers and static RSA key exchange do not exist in TLS 1.3. That is why a TLS 1.3 configuration rarely needs attention, while a TLS 1.2 list still does.

How client and server choose

The client sends the suites it supports in its first message, most preferred first, as it does with application protocols in the ALPN extension. The server picks one it also supports. Most servers can be told to prefer their own order instead of the client's, for example ssl_prefer_server_ciphers in nginx or SSLHonorCipherOrder in Apache. With a list made only of strong suites, either order gives a secure result.

If the two lists share nothing, the server ends the handshake with a handshake_failure alert. Firefox shows that as SSL_ERROR_NO_CYPHER_OVERLAP and Chrome as ERR_SSL_VERSION_OR_CIPHER_MISMATCH; fixes are on cipher mismatch.

Two naming systems

The same suite has two names. The standard name, registered with IANA, is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. OpenSSL and the servers built on it, including nginx and Apache, use their own name: ECDHE-RSA-AES128-GCM-SHA256. TLS 1.3 suites use the standard names everywhere.

OpenSSL prints both side by side:

$ openssl ciphers -stdname -v 'ECDHE-RSA-AES128-GCM-SHA256'
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD

In OpenSSL-based servers, TLS 1.2 suites and TLS 1.3 suites are configured separately. A cipher list such as nginx's ssl_ciphers affects only TLS 1.2 and older; TLS 1.3 suites keep their defaults unless set in their own setting.

Which suites to allow

For a public website the principle is short: TLS 1.3 with its defaults, and for TLS 1.2 only suites with ECDHE key exchange and AEAD encryption (GCM or ChaCha20-Poly1305). Everything else either lacks forward secrecy or uses encryption modes with a history of attacks.

Rather than copying a list from a guide, generate one for your server and the oldest clients you need with the Mozilla SSL Configuration Generator. Lists change as clients move, and a generator is updated; a list pasted into a configuration years ago is not. Which protocol versions to enable is on TLS versions.

How to see what a server offers

To check which suites a server accepts, list them from outside:

$ nmap --script ssl-enum-ciphers -p 443 example.com

To see the suite one connection used, read the handshake summary of openssl s_client, which prints a line such as New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384. To see what a cipher string in a configuration expands to before using it:

$ openssl ciphers -v 'ECDHE+AESGCM:ECDHE+CHACHA20'

An empty result or no cipher match means the string selects nothing. More commands are on OpenSSL commands.

FAQ