TLS Cipher Suites

Cipher Suite Parser

Paste a cipher suite name (TLS 1.2 or TLS 1.3) to see it broken down into its component algorithms.

Modern vs. Legacy Suites

TLS 1.3 cipher suites are AEAD-only with mandatory forward secrecy. Legacy suites include CBC modes, static RSA, and often lack forward secrecy. Hover a row to highlight it.

Cipher Suite Anatomy

A TLS 1.2 cipher suite name encodes four operations. TLS 1.3 separates them into independent extensions, but the old naming convention is still worth understanding for legacy debugging.

Key Exchange: DH, ECDH, DHE, ECDHE

Key exchange establishes the shared secret between client and server without an eavesdropper learning it. DH and ECDH are static (no forward secrecy); DHE and ECDHE are ephemeral (forward secrecy guaranteed).

{`# Diffie-Hellman (static) — RFC 2631
# Both parties have a long-term DH key pair.
# Vulnerable: if an attacker records traffic and later steals one
# party's private key, they can compute the shared secret retroactively.
#
#   ClientDH:  g^a mod p        ServerDH:  g^b mod p
#   Shared:    (g^b)^a = g^ab  Shared:    (g^a)^b = g^ab
#
# NOT USED in TLS (removed in TLS 1.3).

# ECDH (static) — RFC 4492
# Same as DH but on an elliptic curve.
# Uses the formula: shared_secret = a * B = b * A
# where (A, a) are client's keypair, (B, b) are server's keypair.
# NOT forward-secret. Removed in TLS 1.3.

# DHE (ephemeral DH) — forward secrecy via fresh random per session
#   Client:  (g^a mod p,  a is fresh random)
#   Server:  (g^b mod p,  b is fresh random)
#   Shared:  g^ab mod p
# After the handshake a and b are discarded.
# Compromise of either long-term key DOES NOT recover past sessions.

# ECDHE (ephemeral ECDH) — preferred in TLS 1.2 and TLS 1.3
# Same as DHE but on an elliptic curve.
#   - P-256, P-384, P-521 (NIST curves)
#   - X25519 (Curve25519, DJB's curve, constant-time implementation)
#   - secp256k1 (used in Bitcoin, not common in TLS)
#
# X25519 example:
client_private = random(32 bytes)
client_public  = X25519 scalar multiplication(G, client_private)
# Send client_public in ClientHello.key_share
# Server does: shared = X25519(client_private, server_public)
# Both get the same result; eavesdropper cannot (needs private key).

# Python equivalent with cryptography library
python3 << 'EOF'
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
from cryptography.hazmat.primitives import serialization

priv = X25519PrivateKey.generate()
pub  = priv.public_key()
print("Private size:", priv.private_bytes_raw().__len__(), "bytes")
print("Public size: ", pub.public_bytes(serialization.RawEncoding,
      serialization.PublicFormat.Raw).__len__(), "bytes")
EOF
# Private size: 32 bytes
# Public size:  32 bytes
`}

Auth Methods: RSA, ECDSA, Ed25519

The authentication method in a cipher suite determines the signature algorithm used to verify the certificate chain. In TLS 1.3 it is negotiated independently via the signature_algorithms extension, not the cipher suite.

{`# RSA signatures (PKCS#1 v1.5) — legacy, still common
# Certificate contains an RSA public key; server signs the transcript hash
# with the corresponding RSA private key.
#   - Slow signing (RSA-2048: ~0.5ms; RSA-4096: ~2ms)
#   - Large signature (256–512 bytes)
#   - Vulnerable to Bleichenbacher-style oracle attacks on PKCS#1 v1.5
#   - Still widely deployed (Google, Microsoft CAs issue RSA-2048 certs)

# ECDSA (P-256 / P-384) — current standard
# Certificate contains an ECDSA public key (32 or 48 bytes);
# server signs with the corresponding ECDSA private key.
#   - Fast signing (P-256: ~0.05ms)
#   - Smaller signature (64 or 96 bytes vs 256–512 for RSA)
#   - Deterministic (with RFC 6979 nonce generation) — no random failures
#   - Widely supported; most modern CAs issue ECDSA P-256 certs

# Ed25519 — high-performance modern alternative
# Pure Edwards curve; certificate contains Ed25519 public key (32 bytes).
#   - Signing: ~0.02ms (fastest of the three)
#   - Signature: 64 bytes, constant-time verification
#   - No nonce management issues (deterministic by design)
#   - Supported by Let's Encrypt, Smallstep, and most ACME CAs
#   - Not supported by all TLS libraries (OpenSSL 1.1.1+ yes; older no)

# TLS 1.3 signature_algorithms extension (RFC 8446 §4.2.3)
# Client advertises which algorithms it accepts; server picks one.
signature_algorithms = [
  ecdsa_secp256r1_sha256,    # ECDSA P-256 with SHA-256
  rsa_pss_rsae_sha256,       # RSA-PSS with RSA-2048
  ed25519,                   # Ed25519
  rsa_pkcs1_sha256,          # legacy RSA PKCS#1 v1.5 (discouraged)
]`}

Ciphers: AES-CBC vs AES-GCM vs ChaCha20-Poly1305

The bulk cipher encrypts application data. CBC is a block cipher mode requiring padding (which caused POODLE); GCM and ChaCha20-Poly1305 are AEAD modes providing both confidentiality and integrity in one primitive.

{`# AES-GCM: authenticated encryption with associated data
# 1. Generate per-record nonce (12 bytes, unique per record)
# 2. Encrypt: AES-CTR mode with counter starting at nonce
# 3. Authenticate: GMAC over AAD (additional authenticated data)
#    AAD = TLS record header (5 bytes: type, version, sequence number)
# 4. Output: nonce || ciphertext || auth_tag (16 bytes)
# Security: unique nonce is essential; reuse = catastrophic (GCM reuse)

# ChaCha20-Poly1305: stream cipher with MAC
# 1. ChaCha20 stream cipher encrypts (32-byte key, 12-byte nonce, counter)
# 2. Poly1305 authenticator over: key || ciphertext || length
# 3. Poly1305 is a Wegman-Carter authenticator — information-theoretic security
# Advantage on low-end ARM: no AES-NI required; constant-time execution

# Why GCM is preferred for servers:
#   - AES-NI instructions make it ~3x faster on x86-64 server CPUs
#   - NIST-approved; widely certified
# Why ChaCha20 is preferred for mobile:
#   - Constant-time on all architectures (no timing side-channels)
#   - Lower CPU cycle count on devices without AES-NI

# OpenSSL: check what ciphers are available
openssl ciphers -v 'TLS_AES'          # TLS 1.3 ciphers
openssl ciphers -v 'ECDHE+AESGCM'      # TLS 1.2 modern
openssl ciphers -v 'TLSv1.2:!EXP:!LOW' # All TLS 1.2 except export/legacy`}

MAC / PRF: HMAC-SHA256 and TLS 1.3 HKDF

TLS needs a pseudo-random function to derive keys from the master secret (TLS 1.2) or the handshake transcript (TLS 1.3). The PRF has evolved across TLS versions.

{`# TLS 1.2 PRF — RFC 5246
# PRF(master_secret, label, seed) =
#   P_hash(SHA-256, master_secret, label || seed) <>
#   P_hash(SHA-384, master_secret, label || seed)   # for SHA-384 suites
#
# P_hash(Hash, secret, seed) = HMAC_Hash(secret, P_hash(secret, seed+1))
#                             HMAC_Hash(secret, P_hash(secret, seed+2)) ...
# Essentially: HMAC-based key derivation, iterated to expand arbitrarily.
#
# Used for: master_secret derivation, key expansion, Finished MAC

# TLS 1.3 HKDF — RFC 5869, integrated into RFC 8446
# HKDF has two phases:
#   1. HKDF-Extract(salt, IKM) → PRK (pseudorandom key)
#   2. HKDF-Expand-Label(PRK, label, context, length) → OKM (output key material)
#
# HKDF-Extract:  HKDF-Extract(SHA-256, salt, IKM) = HMAC-SHA256(salt, IKM)
# HKDF-Expand-Label: uses HMAC in counter mode to expand PRK into key material
#
# Label format (RFC 8446 §7.1):
#   HKDF-Expand-Label(Secret, Label, Context, Length) =
#     HKDF-Expand(PRK, I2OSP(Length, 2) || label || 0x00 || Context, Length)
#   where label = "tls13 " || ASCII label (e.g., "client_handshake_traffic_secret")
#
# Context = transcript hash (binds key to all handshake messages seen so far)
# This is the key to TLS 1.3's security reduction: the transcript hash
# ties derived keys to everything that happened in the handshake.

# Python: HKDF example
python3 << 'EOF'
import cryptography.hazmat.primitives.hazmat.primitives.hashes as hashes
import cryptography.hazmat.primitives.kdf.hkdf as hkdf
from cryptography.hazmat.backends import default_backend

ikm = b'\\x00' * 32   # pseudo shared secret from ECDHE
hkdf_expand = hkdf.HKDFExpand(
    algorithm=hashes.SHA256(),
    length=64,
    context=b'tls13 client_application_traffic_secret',
    backend=default_backend()
)
key_material = hkdf_expand.expand(ikm)
print("64-byte expanded key material:", key_material.hex())
EOF`}

TLS 1.3 Cipher Suite Changes

TLS 1.3 (RFC 8446) dramatically simplified cipher suite negotiation. Only five cipher suites are registered; forward secrecy is mandatory; and auth is no longer part of the suite name.

{`# The five TLS 1.3 cipher suites:
TLS_AES_128_GCM_SHA256          # mandatory-to-implement
TLS_AES_256_GCM_SHA384          # for high security applications
TLS_CHACHA20_POLY1305_SHA256    # mobile / low-power devices
TLS_AES_128_CCM_SHA256          # mandatory (RFC 8446 §41.2.1)
TLS_AES_128_CCM_8_SHA256        # exportable variant (discouraged)

# What's different from TLS 1.2:
#   1. No static RSA key exchange — RSA can only sign, not encrypt keys
#      (this removes the FREAK, Logjam, and DROWN attack families)
#   2. No CBC cipher modes — removes POODLE, BEAST, Lucky13
#   3. No RC4 — removed due to bias attacks
#   4. No export ciphers — removed (FREAK was an export cipher attack)
#   5. Auth is NOT in the cipher suite name
#      (signature_algorithms extension negotiates auth separately)
#   6. Forward secrecy is mandatory (no RSA key exchange possible)
#   7. 0-RTT uses early_data secret but carries replay risk

# ClientHello in TLS 1.3 carries only the AEAD suite:
#   cipher_suites = [
#     TLS_AES_128_GCM_SHA256,   # 0x1301
#     TLS_AES_256_GCM_SHA384,   # 0x1302
#     TLS_CHACHA20_POLY1305_SHA256  # 0x1303
#   ]
# Server picks one. That's it.

# TLS 1.2 carried auth + cipher + PRF all in one suite:
#   cipher_suites = [
#     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,  # ECDHE key exchange
#                                              # RSA authentication
#                                              # AES-128-GCM cipher
#                                              # SHA-256 PRF
#   ]

# Python: enumerate TLS 1.3 cipher suites
python3 -c "
import ssl, hashlib
suites = [
    ('TLS_AES_128_GCM_SHA256',   b'\\x13\\x01'),
    ('TLS_AES_256_GCM_SHA384',   b'\\x13\\x02'),
    ('TLS_CHACHA20_POLY1305_SHA256', b'\\x13\\x03'),
    ('TLS_AES_128_CCM_SHA256',   b'\\x13\\x04'),
    ('TLS_AES_128_CCM_8_SHA256',  b'\\x13\\x05'),
]
for name, code in suites:
    print(name, '->', code.hex())
"`}

Configuring Cipher Suites

Server-side cipher suite configuration is where theory meets production. A misconfigured server can accept weak suites that compromise security.

{`# nginx: TLS 1.3 only, modern suites only
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers off;  # client chooses among server's list

# Apache
SSLProtocol TLSv1.3
SSLCipherSuite TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
SSLHonorCipherOrder Off

# HAProxy
ssl-default-bind-ciphers TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256

# TLS 1.2 fallback (legacy clients only)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

# Check your server's cipher suites:
openssl s_client -connect example.com:443 -tls1_3 -cipher TLS_AES_128_GCM_SHA256 &1 | grep -i cipher`}

Tradeoffs

FAQ