HTTPS vs HTTP¶

What is it: HTTPS = HTTP + TLS. TLS sits between the TCP layer and the HTTP layer. Every HTTP request/response is encrypted and authenticated by TLS.

What TLS adds: - Confidentiality: request/response bodies, headers (including cookies and auth tokens) are encrypted. A passive eavesdropper on the network sees only encrypted bytes. - Integrity: each TLS record includes a MAC (Message Authentication Code) — tampering with the encrypted bytes is detectable. - Authentication: the server presents a certificate signed by a trusted CA. The client verifies the certificate chain to confirm it is talking to the real server (not a MITM).

Why HTTPS is slower than HTTP: TLS 1.2: 2 extra round trips for handshake before the first HTTP request. TLS 1.3: 1 extra round trip (1-RTT). On a 50ms RTT connection, TLS 1.2 adds 100ms to the first request; TLS 1.3 adds 50ms. After the handshake, TLS adds encryption/decryption CPU overhead (~0.1–0.5ms per request on modern hardware with AES-NI). TLS session resumption (session tickets) allows returning clients to skip the full handshake, reducing overhead to near zero for repeat connections.

TLS overhead is worth it: Without HTTPS, an attacker on the same network (coffee shop WiFi) can read auth tokens, session cookies, and inject malicious content. The latency cost of TLS is small; the security benefit is large. TLS 1.3 with 0-RTT resumption is essentially zero overhead for returning clients.

Common pitfall¶

Terminating TLS at a load balancer and then treating the connection to the backend as automatically safe is a common gap — the diagram above shows TLS as one layer in one connection; a request typically crosses two connections (client-to-LB, LB-to-backend), and only the first one is encrypted unless the second is explicitly configured as TLS too. On a shared internal network this risk is lower but not zero; on a cloud provider where "internal" traffic can still traverse shared infrastructure, unencrypted backend hops are a real, often-overlooked exposure.