Cipher Suite

A cipher suite is a named set of cryptographic algorithms that client and server negotiate during a TLS handshake. It specifies how the session key is established, how the server's identity is authenticated, how data is encrypted, and how message integrity is verified — all in a single agreed name.

What a Cipher Suite Bundles

A TLS 1.2 cipher suite packages four distinct algorithm choices:

• Key exchange. How client and server establish a shared secret without transmitting it. Common choices: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), DHE (finite-field DHE).
• Authentication. How the server proves its identity. Typically RSA or ECDSA, corresponding to the certificate key type.
• Bulk encryption. The symmetric cipher used to encrypt the data stream once the session key is established. Examples: AES-128-GCM, AES-256-GCM, ChaCha20.
• Message integrity (MAC/AEAD). How tampering is detected. GCM and CCM modes are AEAD (Authenticated Encryption with Associated Data) — integrity is built into the cipher itself. In TLS suite names the trailing SHA-256 or SHA-384 names the PRF (TLS 1.2) or HKDF (TLS 1.3) hash and appears even in AEAD suites; a separate HMAC for record integrity exists only in older non-AEAD (CBC) suites.

Reading a TLS 1.2 Suite Name

The naming convention encodes all four components in order:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 │    │     │        │           │
 │    │     │        │           └─ PRF / key-derivation hash (SHA-256)
 │    │     │        └───────────── bulk cipher (AES-128-GCM, AEAD)
 │    │     └────────────────────── authentication (RSA)
 │    └──────────────────────────── key exchange (ECDHE)
 └───────────────────────────────── protocol prefix

The WITH keyword separates the asymmetric (handshake) algorithms from the symmetric (record layer) algorithms.

TLS 1.3 — A Shorter Name, Stronger Guarantee

TLS 1.3 (RFC 8446) redesigned cipher suites by removing the key exchange and authentication components from the name entirely. In TLS 1.3, key exchange is always ephemeral — either ECDHE or DHE — and authentication is handled separately via certificate signature algorithms. The suite name therefore covers only the symmetric layer:

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

RFC 8446 defines exactly five cipher suites for TLS 1.3, all using AEAD ciphers. The reduced set reflects years of cryptographic review: only algorithms with well-understood security properties and efficient implementations were included.

Why ECDHE and Forward Secrecy Matter

Cipher suites using ephemeral key exchange (ECDHE or DHE) provide forward secrecy: the session key is derived from a temporary key pair that is discarded after the handshake. If an attacker records encrypted traffic today and later obtains the server's long-term private key, they cannot decrypt past sessions — each session's ephemeral key is gone. Suites using static RSA key exchange (where the session key is encrypted with the server's long-term public key) do not have this property. TLS 1.3 mandates ephemeral key exchange, eliminating non-forward-secret suites entirely.

See your negotiated cipher with the TLS tool →