principlejavascriptTip
TLS Handshake: What Happens Before the First HTTP Byte
Viewed 0 times
tlshttpshandshakesslrtttls 1.3session resumption
Problem
Developers treat HTTPS as HTTP with a checkbox, unaware that TLS adds latency that can dominate page load time on slow connections.
Solution
Understand the TLS 1.3 handshake to optimize it:
Optimizations:
- Client Hello (1 RTT): client sends supported versions, ciphers, key share
- Server Hello + Certificate + Finished (same RTT): server selects cipher, sends cert, proves identity
- Application data: starts after 1 RTT (TLS 1.3) vs 2 RTT (TLS 1.2)
Optimizations:
- Use TLS 1.3 (1-RTT, sometimes 0-RTT resumption)
- Enable session tickets for resumption
- Use OCSP stapling to avoid cert revocation round trips
- Preload with
<link rel=preconnect>for cross-origin resources
Why
TLS 1.2 requires 2 round trips before any application data flows. On a 100ms RTT connection that's 200ms before the first byte. TLS 1.3 cuts this to 1 RTT (100ms) and 0-RTT resumption eliminates handshake latency entirely for returning connections.
Gotchas
- TLS 0-RTT resumption is vulnerable to replay attacks — do not use for non-idempotent requests.
- Certificate chain order matters: server cert must come first, then intermediates.
- HSTS preloading locks your domain to HTTPS in browsers permanently — only enable when fully committed.
Revisions (0)
No revisions yet.