TLS Cipher Suites: A Complete Guide to Server Security Configuration

What Is a Cipher Suite?

A cipher suite is a set of cryptographic algorithms that together define how a TLS connection is secured. When a client (browser, email server, API client) connects to your server, they negotiate which cipher suite to use during the TLS handshake. The cipher suite determines four aspects of the connection:

• Key Exchange Algorithm — How the client and server agree on shared encryption keys (e.g., ECDHE, DHE, RSA).
• Authentication Algorithm — How the server proves its identity (e.g., RSA, ECDSA).
• Bulk Encryption Algorithm — How the actual data is encrypted (e.g., AES-128-GCM, AES-256-GCM, CHACHA20-POLY1305).
• MAC Algorithm — How message integrity is verified (e.g., SHA-256, SHA-384). In AEAD ciphers like GCM, the MAC is integrated into the encryption algorithm.

A cipher suite name encodes all of these. For example, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 means: ECDHE key exchange, RSA authentication, AES-256-GCM encryption, and SHA-384 for the PRF (pseudorandom function).

TLS 1.3 vs TLS 1.2 Cipher Suites

TLS 1.3 dramatically simplified cipher suite selection. Instead of hundreds of possible combinations, TLS 1.3 supports only five cipher suites, all of which use AEAD encryption and provide forward secrecy by default:

# TLS 1.3 cipher suites (all strong)
TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

In TLS 1.3, the key exchange and authentication algorithms are negotiated separately from the cipher suite, which is why the suite names are shorter. Forward secrecy (via ECDHE or DHE) is mandatory — there is no option to use static RSA key exchange.

TLS 1.2 offers far more cipher suites, including many weak or deprecated options. The security of your TLS 1.2 configuration depends entirely on which cipher suites you enable and in what order. You can test which cipher suites your server supports using our Cipher Suite Checker.

Forward Secrecy: Why It Matters

Forward secrecy (also called perfect forward secrecy or PFS) ensures that if your server's private key is compromised in the future, past encrypted sessions cannot be decrypted. Without forward secrecy, an attacker who records encrypted traffic and later obtains the private key can decrypt every recorded session.

Forward secrecy is provided by ephemeral key exchange algorithms:

• ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) — The recommended key exchange method. Uses elliptic curve cryptography for efficient, strong key agreement. Generates a fresh key pair for every connection.
• DHE (Diffie-Hellman Ephemeral) — The traditional Diffie-Hellman key exchange with ephemeral keys. Slower than ECDHE and requires careful parameter configuration (use 2048-bit DH parameters minimum).

Cipher suites that use static RSA key exchange (where the pre-master secret is encrypted with the server's RSA public key) do not provide forward secrecy and should be disabled. These suites are identified by names starting with TLS_RSA_WITH_.

Strong vs Weak Cipher Suites

In 2026, the following cipher components are considered strong:

• Key exchange: ECDHE (preferred), DHE with 2048+ bit parameters
• Authentication: ECDSA (preferred for performance), RSA (2048+ bit)
• Encryption: AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305
• Hash: SHA-256, SHA-384

The following should be disabled:

• RC4: Biased keystream, multiple practical attacks. Banned by RFC 7465.
• 3DES: 64-bit block size makes it vulnerable to SWEET32 birthday attacks.
• CBC mode ciphers: Vulnerable to padding oracle attacks (POODLE, Lucky13). Use GCM or CHACHA20 instead.
• DES, EXPORT, NULL ciphers: Provide negligible or no encryption. Must never be enabled.
• Static RSA key exchange: No forward secrecy. Disable all TLS_RSA_WITH_* suites.
• SHA-1 / MD5: Cryptographically broken hash functions. All modern suites use SHA-256+.

Recommended Nginx Configuration

Here is a production-ready TLS configuration for Nginx that supports TLS 1.2 and 1.3 with only strong cipher suites:

# /etc/nginx/conf.d/ssl.conf

# Protocols: TLS 1.2 and 1.3 only
ssl_protocols TLSv1.2 TLSv1.3;

# TLS 1.2 cipher suites (server preference)
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';

# Server chooses the cipher (not the client)
ssl_prefer_server_ciphers on;

# ECDH curve
ssl_ecdh_curve X25519:secp384r1:secp256r1;

# Session settings
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;

Recommended Apache Configuration

The equivalent Apache configuration for strong TLS:

# /etc/apache2/conf-available/ssl-params.conf

SSLProtocol -all +TLSv1.2 +TLSv1.3

SSLCipherSuite 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

SSLHonorCipherOrder on

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Disabling Legacy Protocols

As of 2026, the following protocols should be completely disabled on all servers:

• SSL 2.0: Deprecated since 2011 (RFC 6176). Contains critical vulnerabilities including DROWN.
• SSL 3.0: Deprecated since 2015 (RFC 7568). Vulnerable to POODLE attack.
• TLS 1.0: Deprecated since 2021 (RFC 8996). Vulnerable to BEAST attack and lacks modern cipher support.
• TLS 1.1: Deprecated since 2021 (RFC 8996). No support for AEAD ciphers or SHA-256.

Only TLS 1.2 and TLS 1.3 should be enabled. Client support for TLS 1.2 is effectively universal in 2026 — disabling older protocols will not break compatibility with any modern browser or email server.

Testing Your Server's Cipher Configuration

After configuring your server, verify that only the intended cipher suites are enabled:

• Cipher Suite Checker — Scan your server to see all supported cipher suites, ranked by strength, with warnings for weak ciphers.
• TLS Checker — Verify which TLS protocol versions your server supports and identify deprecated protocols.
• SSL Checker — Inspect the full certificate chain, expiration, and TLS configuration in one comprehensive scan.

You can also test from the command line using OpenSSL:

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

# List all supported ciphers
nmap --script ssl-enum-ciphers -p 443 example.com

Cipher Suites for Email Servers

Email servers (SMTP, IMAP, POP3) should use the same strong cipher suite configuration as web servers. The same principles apply: prefer ECDHE for key exchange, use AEAD ciphers (AES-GCM or CHACHA20), and disable legacy protocols. For SMTP specifically, ensure your server supports STARTTLS with strong ciphers, as sending servers will downgrade or refuse connections if only weak ciphers are offered. Pairing strong ciphers with MTA-STS and DANE provides the strongest protection for email in transit.

Related Guides

• TLS Email Encryption: How to Secure Email in Transit
• SSL Certificate Guide: Types, Validation, and Best Practices
• Certificate Chain Explained: How TLS Trust Works