Modern TLS/SSL Configuration for Web Applications

Transport Layer Security (TLS) is the cryptographic protocol powering HTTPS.

TLS Protocol Version Security & Cipher Suite Matrix

In 2021, the IETF formally deprecated TLS 1.0 (RFC 2246) and TLS 1.1 (RFC 4346) via RFC 8996. These legacy protocols rely on obsolete cryptographic primitives (such as MD5 and SHA-1) and are susceptible to fundamental attacks:

• BEAST (Browser Exploit Against SSL/TLS): Exploits predictable Initialization Vectors (IVs) in CBC ciphers.
• POODLE (Padding Oracle On Downgraded Legacy Encryption): Exploits SSL 3.0 and TLS fallback mechanisms.
• CRIME & BREACH: Exploits TLS-level and HTTP-level compression to decrypt session tokens.

Modern production environments must support strictly TLS 1.2 and TLS 1.3, completely rejecting connections from TLS 1.0 and 1.1.

TLS 1.3 (RFC 8446) introduced the most substantial overhaul of transport security in two decades, delivering major security and performance improvements:

1. 1-RTT Handshake Latency

In TLS 1.2, establishing an encrypted connection requires two round-trip times (2-RTT) between client and server before application data can flow. TLS 1.3 reduces this to a single round trip (1-RTT), slashing mobile connection latency.

2. Elimination of Insecure Ciphers

TLS 1.3 permanently removed vulnerable algorithms that plagued TLS 1.2:

• Static RSA key exchange (no Perfect Forward Secrecy)
• CBC-mode ciphers (vulnerable to padding oracles)
• RC4, 3DES, and MD5/SHA-1 hashing

3. Perfect Forward Secrecy (PFS) by Default

TLS 1.3 mandates ephemeral Diffie-Hellman key exchange (ECDHE). If an attacker records encrypted traffic today and steals the server's private key years later, they CANNOT decrypt past communications.

When configuring TLS 1.2 fallback, select cipher suites providing Authenticated Encryption with Associated Data (AEAD) and Ephemeral Elliptic Curve Diffie-Hellman (ECDHE):

Recommended TLS 1.3 Ciphers

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256 (exceptional performance on devices without hardware AES acceleration)

Recommended TLS 1.2 Ciphers (Mozilla Intermediate Profile)

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384

When a browser connects to an HTTPS site, it must verify whether the SSL certificate has been revoked. In traditional Online Certificate Status Protocol (OCSP) verification, the browser makes a direct request to the Certificate Authority (CA). This creates a performance bottleneck and leaks user browsing history to the CA.

OCSP Stapling solves this by having the web server periodically query the CA for a signed timestamped revocation proof, which it caches and 'staples' directly to the TLS handshake response. This eliminates client-side lookup delays and preserves visitor privacy.

A CAA record is a DNS resource record that specifies which Certificate Authorities are authorized to issue certificates for your domain name. All compliant CAs (Let's Encrypt, DigiCert, Sectigo) are required by CA/Browser Forum rules to check CAA records before issuing certificates:

# DNS Zone file example: Only allow Let's Encrypt and report violations
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:security@example.com"

This prevents attackers from tricking a rogue or compromised secondary CA into issuing unauthorized certificates for your domain.

Below is a battle-tested Nginx configuration supporting 99.9% of modern clients while maintaining an SSL Labs A+ rating:

TLS 1.3 introduced 0-RTT (Zero Round Trip Time) Resumption, allowing returning visitors to transmit application data alongside the initial ClientHello packet, achieving instant connection setup.

The Replay Attack Hazard:

0-RTT Early Data does not provide forward secrecy and cannot guarantee replay defense at the TLS layer. If an attacker records an encrypted 0-RTT packet (e.g., POST /api/transfer-funds), they can replay that exact packet multiple times to your server.

Production Mitigation Rules:

1. Never Allow State-Changing Requests via 0-RTT: Web servers must restrict 0-RTT data exclusively to idempotent HTTP requests (GET, HEAD).
2. Deploy Nginx Anti-Replay Directives: Use ssl_early_data on; only in conjunction with proxy headers that check $ssl_early_data and reject non-idempotent methods:

# Restrict 0-RTT to idempotent GET requests only
if ($ssl_early_data = "1") {
    set $early_data_check "1";
}
if ($request_method = "POST") {
    set $early_data_check "${early_data_check}post";
}
if ($early_data_check = "1post") {
    return 425; # 425 Too Early
}