TLS/SSL Reference

TLS 1.3 (2018) provides several major improvements over TLS 1.2 (2008). The handshake is reduced from 2 round trips to 1 round trip, and 0-RTT session resumption is supported. All insecure algorithms are removed — no RSA key exchange, no CBC mode, no RC4, no SHA-1, no static DH. Only AEAD ciphers (AES-GCM, ChaCha20-Poly1305) and ephemeral key exchange (ECDHE) are permitted, guaranteeing forward secrecy for all connections.

TLS 1.0 and 1.1 were deprecated in 2021 (RFC 8996) because they are vulnerable to well-known attacks including POODLE (which exploits CBC padding in SSL 3.0/TLS 1.0), BEAST (which targets CBC mode initialization vectors in TLS 1.0), and they lack support for modern AEAD ciphers. All major browsers removed support for these versions. TLS 1.2 with AEAD ciphers is now the minimum acceptable version.

TLS_AES_128_GCM_SHA256 is the most widely deployed and is the recommended default. TLS_AES_256_GCM_SHA384 offers a larger key size for environments requiring 256-bit encryption (e.g., government compliance). TLS_CHACHA20_POLY1305_SHA256 is recommended for mobile clients and ARM devices that lack AES hardware acceleration (AES-NI), as ChaCha20 achieves better performance in software-only implementations.

Forward secrecy (also called perfect forward secrecy) means that even if the server's long-term private key is compromised, past recorded traffic cannot be decrypted. This is achieved by using ephemeral key exchange (ECDHE or DHE) where a unique session key is generated for each connection and discarded after use. RSA key exchange lacks this property — if the RSA private key is later leaked, all previously captured traffic can be decrypted. TLS 1.3 mandates forward secrecy by only allowing ephemeral key exchange.

SNI (Server Name Indication) is a TLS extension that includes the target hostname in the Client Hello message, allowing a server at a single IP address to present the correct certificate for the requested domain. Because the Client Hello is sent before encryption is established, the SNI hostname is visible to network observers. Encrypted Client Hello (ECH) is the solution — it encrypts the SNI using a public key published in DNS, preventing passive observation of which site the client is connecting to.

0-RTT (zero round-trip time) allows a client that has previously connected to a server to send encrypted application data in its very first message during session resumption, using a Pre-Shared Key (PSK) from the previous session. This eliminates the handshake latency entirely for returning connections. The tradeoff is that 0-RTT data is vulnerable to replay attacks — an attacker who captures the 0-RTT message can resend it to the server. Servers must implement application-layer replay protection for any non-idempotent operations.

ALPN (Application-Layer Protocol Negotiation) is a TLS extension that lets the client and server agree on which application protocol to use (such as h2 for HTTP/2 or http/1.1 for HTTP/1.1) during the TLS handshake itself, before any application data is sent. This avoids an extra round trip that would be needed if protocol negotiation happened after the TLS connection was established. ALPN is required for HTTP/2 — browsers will only use HTTP/2 over TLS connections that successfully negotiate h2 via ALPN.

Yes. The reference provides the technical details needed to evaluate TLS configurations against standards like PCI DSS (which requires TLS 1.2 or higher), NIST SP 800-52 (which recommends TLS 1.3 and specific cipher suites), and general security best practices. You can quickly look up which cipher suites are considered secure, which key exchange algorithms provide forward secrecy, and which TLS versions are deprecated — all critical information for security audits and compliance assessments.