What are Cipher Suites

A cipher suite is a named combination of cryptographic algorithms that a TLS connection uses for key exchange, server authentication, data encryption, and message integrity. During the TLS handshake, the client sends a list of cipher suites it supports (in preference order), and the server selects one that both sides support. This single negotiation determines the security properties of the entire connection — forward secrecy, encryption strength, and authentication method.

Why it matters

• Security floor — the weakest cipher suite your server accepts defines your minimum security. If you support TLS_RSA_WITH_RC4_128_SHA, an attacker can force a downgrade to that broken cipher.
• Forward secrecy — cipher suites with ECDHE or DHE provide forward secrecy (past sessions stay encrypted even if the server key is later compromised). Suites with RSA key exchange do not.
• Performance — AES-GCM with AES-NI hardware is faster than ChaCha20 on x86 servers. ChaCha20 is faster on mobile devices without AES-NI. Cipher suite selection affects CPU usage at scale.
• Compliance — PCI DSS, HIPAA, FedRAMP, and other frameworks mandate specific cipher suites and prohibit others. Your cipher suite configuration is an audit item.
• Client compatibility — disabling all legacy cipher suites may lock out older clients (Java 7, Windows XP, Android 4.x). The trade-off between security and compatibility is made in cipher suite configuration.

How it works

TLS 1.2 cipher suite naming:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│     │     │         │       │     │
│     │     │         │       │     └─ Hash: SHA-384 (PRF + HMAC)
│     │     │         │       └─────── Mode: GCM (authenticated)
│     │     │         └─────────────── Encryption: AES-256
│     │     └───────────────────────── Authentication: RSA certificate
│     └─────────────────────────────── Key Exchange: ECDHE (forward secrecy)
└───────────────────────────────────── Protocol: TLS

TLS 1.3 cipher suite naming (simplified):

TLS_AES_256_GCM_SHA384
│     │       │     │
│     │       │     └─ Hash: SHA-384 (HKDF)
│     │       └─────── Mode: GCM
│     └─────────────── Encryption: AES-256
└───────────────────── Protocol: TLS
# Key exchange is always ECDHE (negotiated separately)
# Authentication is always certificate-based (negotiated separately)

Negotiation flow:

1. Client sends ClientHello with ordered list of supported cipher suites
2. Server selects the first cipher suite from the client’s list that it also supports (or its own preferred order if ssl_prefer_server_ciphers is on)
3. Selected cipher suite determines all cryptographic operations for the session

In real systems

Nginx — recommended TLS 1.2 + 1.3 configuration:

ssl_protocols TLSv1.2 TLSv1.3;

# TLS 1.3 suites (configured separately in OpenSSL 1.1.1+)
ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;

# TLS 1.2 suites (only ECDHE + AEAD)
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

ssl_prefer_server_ciphers off;  # Let client choose (TLS 1.3 recommendation)

Testing cipher suites:

# Check what a server supports
nmap --script ssl-enum-ciphers -p 443 example.com

# Test specific cipher suite
openssl s_client -connect example.com:443 -cipher ECDHE-RSA-AES256-GCM-SHA384

# Check TLS 1.3 specifically
openssl s_client -connect example.com:443 -tls1_3 -ciphersuites TLS_AES_256_GCM_SHA384

AWS ALB security policies:

ELBSecurityPolicy-TLS13-1-2-2021-06  → TLS 1.3 + strong TLS 1.2 suites
ELBSecurityPolicy-2016-08            → Legacy (includes weaker suites)
ELBSecurityPolicy-FS-1-2-Res-2020-10 → Forward secrecy only, restricted

Cipher suites to NEVER enable:

TLS_RSA_WITH_*              → No forward secrecy (RSA key transport)
*_RC4_*                     → RC4 is broken
*_3DES_*                    → 3DES has 64-bit block (Sweet32 attack)
*_CBC_*                     → Padding oracle attacks (BEAST, Lucky13)
*_NULL_*                    → No encryption at all
*_EXPORT_*                  → Intentionally weakened (40/56-bit keys)
*_MD5                       → MD5 is broken

Where it breaks

Cipher suite mismatch — server configured with TLS 1.3 only suites, but client only supports TLS 1.2. The handshake fails with handshake_failure. Common with legacy Java applications (Java 8 without updates doesn’t support TLS 1.3). Always check your client population before restricting cipher suites.

Server prefers weak suite — ssl_prefer_server_ciphers on with a misconfigured cipher list that puts a weak suite first. The server forces all clients to use the weak suite even though both sides support stronger options. Always order cipher suites strongest-first if using server preference.

CBC suites still enabled — a server supports ECDHE-RSA-AES256-CBC-SHA384 alongside GCM suites. A downgrade attack (or client that prefers CBC) negotiates the CBC suite, exposing the connection to padding oracle attacks. Remove all CBC suites from your configuration — there’s no reason to keep them when GCM is universally supported.

Operational insight

TLS 1.3’s greatest security improvement isn’t any single algorithm — it’s the elimination of choice. TLS 1.2 has hundreds of cipher suite combinations, many insecure. Administrators must know which to enable and which to disable. TLS 1.3 has exactly 5 cipher suites, all secure: you literally cannot configure an insecure TLS 1.3 connection. The key exchange (ECDHE) and forward secrecy are mandatory, not optional. If your infrastructure supports TLS 1.3, the cipher suite configuration problem disappears. The remaining challenge is TLS 1.2 fallback — which you’ll need until your last legacy client is upgraded.

Related topics

• TLS 1.3 vs TLS 1.2
• What is a TLS Handshake
• What is AES
• Key Exchange (Diffie-Hellman, ECDHE)
• Elliptic Curve Cryptography