/PLAYBOOK · 2026-08-22

TLS Protocol Hardening in Practice: Disabling Weak Ciphers on Nginx

From TLS 1.0/1.1 protocol bugs to RC4 and 3DES weak suites. Complete Nginx TLS hardening: ssl_protocols, ssl_ciphers, session tickets, with OpenSSL verification. Disable weak ciphers end to end.

TLS protocol hardening is the key HTTPS defense against protocol-layer attacks. Core: disable legacy protocols and weak ciphers. For Nginx operators: how to fully disable TLS 1.0/1.1 and RC4/3DES via ssl_protocols, ssl_ciphers, plus OpenSSL verification. Meets MLPS and PCI DSS transport-encryption compliance.

Applicable Scenarios

Scan reports flag "supports TLS 1.0/1.1" or "uses weak cipher suites"
Need MLPS 2.0, PCI DSS, commercial-crypto evaluation compliance items
HTTPS site wants Forward Secrecy and better handshake performance
Nginx reverse-proxy backends have explicit transport-security requirements

Prerequisites

Nginx 1.18+ (older builds lack some directives)
OpenSSL 1.1.1+ (TLS 1.3)
Valid SSL certificate; site already serves HTTPS

How It Works

During TLS handshake, client and server negotiate protocol version and cipher suite; result is the intersection of both support lists. If the server still offers TLS 1.0/1.1, attackers can downgrade via known attacks such as BEAST, POODLE (SSLv3), Lucky13. RC4 has systematic bias attacks; 3DES is hit by SWEET32 (CVE-2016-2183) birthday attack—64-bit block ciphers collide within 32GB of data and leak information. Hardening: keep only TLS 1.2/1.3; cipher list contains only Forward Secrecy (ECDHE) strong suites; disable session tickets that leak.

Procedure

Step 1: Inspect Current TLS Config

`# Inspect existing ssl-related directives
nginx -T 2>/dev/null | grep -E "ssl_protocols|ssl_ciphers|ssl_session"
# Check OpenSSL version (must be ≥ 1.1.1 for TLS 1.3)
openssl version`

Step 2: Strong TLS Config (Mozilla Intermediate)

`# Append in the server block, or put in ssl.conf then include
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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
# Enable HSTS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;`

Key points: ssl_protocols TLSv1.2 TLSv1.3 explicitly excludes TLSv1/TLSv1.1; ssl_ciphers are all GCM/CHACHA20 AEAD suites, all ECDHE/DHE Forward Secrecy; ssl_session_tickets off disables stateless tickets, avoiding session decryption if ticket keys are stolen.

Step 3: Test and Reload

`nginx -t
systemctl reload nginx   # or nginx -s reload`

Configuration Verification

`# 1. TLS 1.0/1.1 must fail (no protocols available or handshake failure)
openssl s_client -connect your-domain.com:443 -tls1 -brief 2>&1 | head -2
openssl s_client -connect your-domain.com:443 -tls1_1 -brief 2>&1 | head -2
# 2. TLS 1.2 / 1.3 must succeed
openssl s_client -connect your-domain.com:443 -tls1_2 -brief &1 | grep -E "Protocol|Cipher"
openssl s_client -connect your-domain.com:443 -tls1_3 -brief &1 | grep -E "Protocol|Cipher"
# 3. Inspect the currently negotiated cipher suite and certificate chain
echo | openssl s_client -connect your-domain.com:443 2>/dev/null | grep -E "New, TLS|Cipher is"`

FAQ

Q1: After disabling TLS 1.0/1.1, IE and other old browsers cannot connect?

IE11 on Windows 7 and mainstream Chinese browsers already support TLS 1.2; real impact is tiny. If you truly have old endpoints (e.g. Windows XP intranet devices), open TLSv1 only on a specific location or listen port; keep the rest strong. Do not roll back globally.

Q2: Why turn off ssl_session_tickets?

TLS session tickets are encrypted with a server key. If that key leaks (backdoor, log leak), an attacker can decrypt any historical session. Key rotation for stateless tickets is often neglected. High-security sites should disable. If you enable, rotate via ssl_session_ticket_key on a schedule and protect the keys.

Q3: Is a longer cipher list better?

No. Longer lists raise handshake cost, and a weak suite mixed in can be selected. Keep only the GCM/CHACHA20 Forward Secrecy suites above. Add ECDHE-RSA-AES128-SHA (AES-CBC) only if you must support Windows XP/old Android, and accept the performance/security tradeoff.

Summary

TLS hardening core is "keep only the strong, explicitly exclude": protocol versions TLS 1.2/1.3 only, ciphers Forward Secrecy strong suites only, session tickets off, plus HSTS and OCSP Stapling. After the steps above, verify each item with openssl s_client. That clears mainstream scanner transport-security checks and meets MLPS and PCI DSS.