Handshake protocol, certificate chains, cipher suites, forward secrecy, mutual TLS, OCSP stapling, HSTS, and why outdated TLS versions are one of the most common production misconfigurations.
TLS (Transport Layer Security) is the protocol that encrypts nearly all web traffic. Every HTTPS connection, every API call, every secure WebSocket runs over TLS. Understanding the handshake - how keys are exchanged, certificates are validated, and cipher suites are negotiated - is fundamental to web security engineering.
TLS was preceded by SSL (Secure Sockets Layer), developed by Netscape in the mid-1990s. SSL 1.0 and 2.0 were fundamentally broken; SSL 3.0 (1996) was the first widely deployed version. TLS 1.0 (RFC 2246) effectively replaced SSL 3.0 with a name change and minor improvements. TLS 1.1 and 1.2 added cipher suite flexibility and removed insecure primitives. TLS 1.0 and 1.1 were formally deprecated in 2020 by all major browsers and RFC 8996.
The handshake is the core of TLS. In TLS 1.3 (RFC 8446, 2018), the handshake completes in one round trip (1-RTT) for new connections and zero round trips (0-RTT) for returning clients using session resumption. The client sends a ClientHello message listing supported protocol versions, cipher suites, and key-share extensions (for ECDHE key exchange). The server responds with a ServerHello that selects the protocol version and cipher suite, along with its certificate, a signed key-share, and a finished message. The client verifies the certificate, computes the shared secret, and sends its finished message. After that, encrypted application data flows in both directions.
TLS 1.3 Handshake (1-RTT):
Client Server
| |
|-------- ClientHello --------------->|
| (versions, cipher suites, |
| key_share, sig_algs) |
| |
|<------- ServerHello ----------------|
| (chosen version, cipher suite, |
|<------ EncryptedExtensions ---------|
|<------ Certificate -----------------|
|<------ CertificateVerify -----------|
|<------ Finished --------------------|
| |
|-------- Finished ------------------>|
| |
|<===== Encrypted Application Data ==>|TLS 1.2 requires two round trips (2-RTT) for a full handshake. The server sends its certificate, a ServerKeyExchange (for key agreement), and ServerHelloDone before the client responds with ClientKeyExchange, ChangeCipherSpec, and Finished. TLS 1.3 eliminated several insecure features from 1.2: static RSA key exchange (no forward secrecy), CBC mode ciphers, RC4, 3DES, SHA-1, and compression. The result is a simpler, faster, and more secure protocol.
Certificate chains establish trust. A server presents a leaf certificate signed by an intermediate CA, which is signed by a root CA. The client's trust store contains the root CA certificates - roughly 150 authorities trusted by default in most browsers and operating systems. OCSP stapling lets the server include a signed, timestamped OCSP response proving the certificate has not been revoked, avoiding the privacy and latency cost of the client contacting the CA directly.
Cipher suites in TLS 1.3 are simpler than in 1.2. A typical suite looks like TLS_AES_128_GCM_SHA256. The TLS_ prefix indicates TLS 1.3. AES_128_GCM is the bulk encryption algorithm (AES in Galois/Counter mode). SHA256 is the hash used for key derivation. TLS 1.3 mandates forward secrecy for all key exchanges: the server generates ephemeral Diffie-Hellman keys per session, so compromising the server's long-term key does not decrypt past recordings.
Mutual TLS (mTLS) requires the client to present a certificate, reversing the standard authentication direction. It is common in API-to-API communication within zero-trust networks and financial systems. HSTS (HTTP Strict-Transport-Security) is a response header that tells browsers to always connect via HTTPS for a specified duration, even if the user types http:// manually. A preloaded HSTS list in browsers ships with domains that should never be accessible over HTTP.
Click "Start Handshake" to watch the TLS 1.3 messages flow between client and server. Toggle between TLS 1.2 and 1.3 to see the extra round trip, and switch between valid and expired certificates to see how browsers warn users.
TLS 1.0 and 1.1 were deprecated in 2020 by RFC 8996 and all major browsers. Any server still supporting these versions will receive warnings or connection failures. TLS 1.2 remains widely deployed and is considered secure when configured with AEAD ciphers (AES-GCM or ChaCha20-Poly1305) and ECDHE key exchange. TLS 1.3 adoption has grown steadily, reaching roughly 40% of web traffic by 2024.
The most common TLS misconfigurations are: allowing weak cipher suites (RC4, CBC mode, 3DES), expired certificates (browsers show full-page warnings), missing HSTS (users can be downgraded to HTTP on subsequent visits), self-signed certificates in production (browsers reject them entirely), and certificate pinning failures (pins that are too rigid cause outages when providers rotate certs). Tools like SSL Labs' SSL Server Test and testssl.sh help audit deployments.
Performance considerations matter. TLS 1.3's 1-RTT handshake and 0-RTT resumption dramatically reduce connection latency compared to TLS 1.2's 2-RTT. Session resumption via session tickets means returning clients can skip the full handshake entirely. OCSP stapling eliminates the client's need to fetch revocation status from the CA, saving another round trip.
Disable TLS 1.0 and 1.1. Configure your server to prefer TLS 1.3 and fall back to TLS 1.2 with a modern cipher suite: ECDHE+AESGCM:ECDHE+CHACHA20. Avoid DHE key exchange (slower than ECDHE), CBC mode ciphers, and static RSA key exchange (no forward secrecy). Set HSTS with a max-age of at least one year (63072000) and the includeSubDomains flag.
Automate certificate renewal with ACME clients like Certbot or Lego. Use a certificate monitoring service to alert on expiration before browsers start showing warnings. Enable OCSP stapling on your web server to improve client-side performance and privacy. Consider using a certificate transparency log to detect misissued certificates for your domain.
For internal services, use a private CA rather than self-signed certificates. Deploy mTLS for API-to-API communication within zero-trust architectures. Regularly audit your TLS configuration with automated scanners and maintain an up-to-date certificate pin set if pinning is necessary (prefer certificate transparency over pinning).
1.How many round trips does a full TLS 1.3 handshake require?
2.What security property does ECDHE key exchange provide that static RSA does not?
3.What is the purpose of the HSTS header?