TLS cipher suites with OpenSSL, GnuTLS and NSS names

TLS_NULL_WITH_NULL_NULL

The placeholder suite of a connection before the first handshake completes: no key exchange, no authentication, no protection.

TLS_NULL_WITH_NULL_NULL (0x00,0x00) describes the initial state of a TLS 1.2 connection (RFC 5246 §6.1). It is never negotiated; a server that selects it has a serious bug.

TLS_RSA_WITH_RC4_128_SHA

RC4 with SHA-1 and RSA key transport, once a popular choice against BEAST, now prohibited by RFC 7465.

RC4 avoided the CBC attacks of 2011–2013 and was briefly recommended for that reason, but its keystream biases let attackers recover plaintext that is sent repeatedly, such as cookies. RFC 7465 §2 says clients MUST NOT include RC4 suites in the ClientHello and servers MUST NOT select them.

TLS_RSA_WITH_3DES_EDE_CBC_SHA

The suite TLS 1.1 made mandatory to implement; its 64-bit blocks made it vulnerable to the Sweet32 birthday attack.

RFC 4346 §9 required TLS 1.1 implementations to support TLS_RSA_WITH_3DES_EDE_CBC_SHA (OpenSSL: DES-CBC3-SHA). Triple DES has 64-bit blocks, so after about 2^32 blocks under one key, collisions leak plaintext; the 2016 Sweet32 attack recovered HTTP cookies that way from long-lived connections.

It also lacks forward secrecy. Modern libraries disable it by default, and IANA marks it Discouraged.

TLS_RSA_WITH_AES_128_CBC_SHA

The suite TLS 1.2 made mandatory to implement; it has no forward secrecy and uses CBC, and RFC 10015 now forbids it.

RFC 5246 §9 required every TLS 1.2 implementation to support TLS_RSA_WITH_AES_128_CBC_SHA (OpenSSL: AES128-SHA), so it is the last-resort suite of many old clients. With RSA key transport the client encrypts the premaster secret to the server's certificate key: anyone who later obtains that key can decrypt every recorded session.

CBC with MAC-then-encrypt exposed it to padding-oracle attacks such as Lucky Thirteen. RFC 10015 §4 now says clients MUST NOT offer and servers MUST NOT select RSA key-exchange suites in TLS 1.2.

TLS_EMPTY_RENEGOTIATION_INFO_SCSV

A signalling value, not a real suite: the client supports secure renegotiation (RFC 5746).

Clients put TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00,0xFF) into the cipher list to signal support for secure renegotiation without sending an extension. RFC 5746 §3.3 introduced it because some servers mishandled extensions; it 'cannot be negotiated'. The renegotiation fix closed the 2009 attack in which an attacker spliced its own data in front of a client's renegotiated session.

TLS_AES_128_GCM_SHA256

The cipher suite every TLS 1.3 implementation must support: AES-128 in GCM mode with SHA-256 for the key schedule.

RFC 8446 §9.1 makes TLS_AES_128_GCM_SHA256 mandatory to implement in TLS 1.3, and RFC 9846, its successor, keeps the requirement. In TLS 1.3 a suite names only the AEAD and the hash of HKDF; key exchange (for example X25519MLKEM768) and the signature (for example ecdsa_secp256r1_sha256) are negotiated in separate extensions.

OpenSSL configures TLS 1.3 suites with -ciphersuites, not with the -cipher string used for TLS 1.2, which is why changing a server's cipher list often leaves TLS 1.3 untouched.

TLS_AES_256_GCM_SHA384

AES-256-GCM with SHA-384, one of the two TLS 1.3 suites that RFC 8446 says implementations SHOULD support.

TLS_AES_256_GCM_SHA384 pairs a 256-bit AES key with SHA-384 in the key schedule. RFC 8446 §9.1 lists it, with TLS_CHACHA20_POLY1305_SHA256, as a SHOULD; most servers offer it, and CNSA-aligned profiles require it.

Grover's algorithm would at best halve the effective key length of AES against a quantum attacker, so AES-256 keeps a wide margin; NIST considers AES-128 adequate as well, because such attacks parallelise poorly.

TLS_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305, the TLS 1.3 suite that is fast in software on devices without AES instructions.

TLS_CHACHA20_POLY1305_SHA256 uses the ChaCha20 stream cipher with the Poly1305 authenticator (RFC 8439). It runs in constant time without hardware support, which made it the preferred suite on mobile devices without AES instructions; servers commonly honour a client that lists it first.

RFC 8446 §9.1 says TLS 1.3 implementations SHOULD support it. The TLS 1.2 counterparts are TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 and TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (RFC 7905).

TLS_AES_128_CCM_SHA256

AES-128-CCM for TLS 1.3, used mainly in constrained devices that already have AES-CCM hardware.

CCM combines AES-CTR encryption with an AES-CBC-MAC and is common in IoT radios. TLS_AES_128_CCM_SHA256 is marked Recommended by IANA, unlike TLS_AES_128_CCM_8_SHA256, whose 8-byte tag IANA does not recommend for general use.

TLS_FALLBACK_SCSV

A signalling value that tells a server the client is retrying with a lower protocol version (RFC 7507).

Clients that retried failed handshakes with older protocol versions could be pushed down to SSL 3.0 by an attacker, which POODLE exploited in 2014. A client sends TLS_FALLBACK_SCSV (0x56,0x00) on such a retry; a server that supports a higher version than the client offers then aborts with inappropriate_fallback instead of continuing. TLS 1.3's downgrade sentinel in ServerHello.random makes the mechanism unnecessary between TLS 1.3 peers.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

The common TLS 1.2 suite for ECDSA certificates: ECDHE key exchange, ECDSA authentication and AES-128-GCM.

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) gives forward secrecy through an ephemeral ECDHE key and authenticates the server with an ECDSA certificate, usually on P-256. It is the TLS 1.2 suite that browsers prefer when the server has an ECDSA certificate.

In OpenSSL cipher strings it is ECDHE-ECDSA-AES128-GCM-SHA256. A server with only an RSA certificate cannot negotiate it — the authentication part of a TLS 1.2 suite must match the certificate's key type.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

The TLS 1.2 suite that HTTP/2 requires: ECDHE key exchange, RSA authentication and AES-128-GCM.

RFC 9113 §9.2.2 requires HTTP/2 deployments that use TLS 1.2 to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with the P-256 curve, so that a client and a server that both follow the HTTP/2 restrictions on TLS 1.2 always share a suite.

OpenSSL calls it ECDHE-RSA-AES128-GCM-SHA256. Despite the name, the RSA key only signs the handshake; the session key comes from the ephemeral ECDHE exchange, so the suite has forward secrecy.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

The 256-bit sibling of the most common TLS 1.2 suite: ECDHE, RSA authentication, AES-256-GCM and the SHA-384 PRF.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) is offered by nearly every TLS 1.2 server with an RSA certificate. The SHA384 in its name sets the hash of the TLS 1.2 PRF; GCM itself needs no separate MAC.

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

ChaCha20-Poly1305 for TLS 1.2 with ECDHE key exchange and an ECDSA certificate (RFC 7905).

Added to TLS 1.2 in 2016, this suite brought the software-friendly ChaCha20-Poly1305 AEAD to servers that could not yet offer TLS 1.3. IANA marks it Recommended. OpenSSL names it ECDHE-ECDSA-CHACHA20-POLY1305.