Education

Cryptography Fundamentals

What are Cipher Suites

What are Cipher Suites

Ayush Kumar Rai May 2, 2026

Key Takeaways

A cipher suite specifies four algorithms: key exchange (ECDHE), authentication (RSA/ECDSA), bulk encryption (AES-256-GCM), and hash (SHA-384)

TLS 1.3 simplified cipher suites to just 5 options — all with forward secrecy and AEAD encryption. No insecure choices possible.

TLS 1.2 has hundreds of cipher suites including insecure ones — server configuration must explicitly disable weak options

Cipher suite order determines which algorithm is used when client and server both support multiple options

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.

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:

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.

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.

Ready to Secure Your Enterprise?

Experience how our cryptographic solutions simplify, centralize, and automate identity management for your entire organization.