TLS/SSL Handshake

The TLS (Transport Layer Security) handshake is the process by which a client and server negotiate encryption parameters, verify the server's identity, and establish a shared secret key for encrypting all subsequent communication.

What It Really Means

When you visit https://example.com, your browser does not just connect and start sending data. Before any HTTP request is sent, the browser and server perform a cryptographic negotiation called the TLS handshake. This handshake achieves three things:

1. Authentication: The browser verifies the server is who it claims to be (via certificates signed by trusted Certificate Authorities)
2. Key exchange: Both sides agree on a shared secret key without ever transmitting it over the network
3. Cipher agreement: Both sides agree on which encryption algorithms to use

TLS replaced SSL (Secure Sockets Layer) and is the protocol behind HTTPS. SSL versions are deprecated due to security vulnerabilities. When people say "SSL certificate," they usually mean a TLS certificate.

The handshake adds latency — 1-2 round trips before data flows. TLS 1.3 reduced this to 1 round trip (and supports 0-RTT for resumed connections), making HTTPS nearly as fast as HTTP for repeat visitors.

How It Works in Practice

TLS 1.2 Handshake (2 round trips)

TLS 1.3 Handshake (1 round trip)

TLS 1.3 0-RTT (Session Resumption)

Implementation

Checking TLS configuration:

Nginx TLS configuration:

Trade-offs

TLS 1.2 vs 1.3:

Performance optimizations:

• Session resumption: Reuse a previous session's keys (avoids full handshake)
• OCSP stapling: Server provides certificate validity proof (avoids client querying CA)
• HTTP/2: Single TLS connection for all requests to a domain
• TLS 1.3: 1-RTT handshake, 0-RTT for resumed connections

Security considerations:

• 0-RTT data is vulnerable to replay attacks. Only use for idempotent requests (GET, not POST).
• Certificate pinning prevents MITM attacks but complicates certificate rotation.
• HSTS (HTTP Strict Transport Security) prevents downgrade attacks.

Common Misconceptions

• "SSL and TLS are different things" — TLS is the successor to SSL. All SSL versions (1.0, 2.0, 3.0) are deprecated and insecure. "SSL certificate" is a legacy term for what is actually a TLS certificate.
• "HTTPS is significantly slower than HTTP" — With TLS 1.3 and session resumption, the overhead is 1 RTT for new connections and 0 RTT for resumed connections. HTTP/2 (TLS-only in browsers) is often faster than HTTP/1.1 over plain HTTP.
• "A valid certificate means the site is safe" — A certificate proves identity (this is really example.com), not safety. Phishing sites can have valid certificates.
• "Self-signed certificates provide no security" — They provide encryption (confidentiality). They do not provide authentication (you cannot verify who you are talking to). Acceptable for internal services with certificate pinning.
• "You need to buy certificates" — Let's Encrypt provides free, automated TLS certificates trusted by all major browsers.

How This Appears in Interviews

1. "What happens when you type https://example.com?" — DNS, TCP handshake, TLS handshake (describe the full negotiation), HTTP request.
2. "How does HTTPS prevent man-in-the-middle attacks?" — Certificate chain verification, asymmetric key exchange, symmetric encryption for data.
3. "How do you optimize HTTPS performance?" — TLS 1.3, session resumption, OCSP stapling, HTTP/2, connection reuse.
4. "What is forward secrecy?" — Even if the server's private key is compromised later, past sessions cannot be decrypted because ephemeral keys were used.

Related Concepts

• TCP Three-Way Handshake — TLS handshake happens after TCP is established
• HTTP/2 Multiplexing — single TLS connection for multiple requests
• DNS Resolution — happens before TCP and TLS
• CORS — browser security policy enforced over HTTPS
• What Happens When You Type a URL — full request lifecycle
• System Design Interview Guide
• Algoroq Pricing — access all concept deep-dives