HTTPS and TLS

HTTP alone sends everything — headers, cookies, request bodies — as plain text anyone on the network path can read: your ISP, a public Wi-Fi operator, anyone running a packet sniffer on a shared network. HTTPS is plain HTTP, unchanged, sent through TLS (Transport Layer Security), which adds three guarantees TLS handles entirely below the application:

Encryption needs a shared secret key — but the client and server have never spoken before this connection, and everything they send is potentially visible to an eavesdropper. Sending the key itself over the connection would defeat the purpose immediately. Asymmetric (public-key) cryptography solves this: a public key can encrypt something only the matching private key can decrypt, so a shared secret can be established even over a connection an attacker is actively watching.

Public-key crypto is computationally expensive, so it's only used to establish a shared session key — after that, both sides switch to much faster symmetric encryption (same key, both directions) for the actual data. This handshake is also in addition to the TCP handshake from two lessons ago — one real reason HTTPS connections are slower to establish than plain HTTP, and exactly the cost HTTP/3's QUIC folds away by combining both handshakes into one.

Encryption alone doesn't prove identity — nothing stops an attacker from generating their own key pair and pretending to be example.com. A certificate, issued by a trusted Certificate Authority (CA), is the CA cryptographically vouching: "we verified that whoever controls this private key also controls example.com." Your browser ships with a built-in list of CAs it trusts; a certificate signed by any of them is accepted, one signed by nobody (or self-signed) triggers the "connection is not private" warning.

Certificates expire on purpose (rarely more than ~13 months in modern practice) — a real production outage that happens more often than it should is a certificate quietly expiring with nobody monitoring for it, which is exactly why automated renewal (Let's Encrypt's ACME protocol, or a cloud provider's managed certificates) has become the default rather than a manual, easy-to-forget task.

In a real deployment, TLS is very often decrypted ("terminated") at a load balancer or CDN edge, with plain, unencrypted HTTP used for the remaining hop to your actual application server inside a private network:

This is a deliberate, common trade-off — decrypting once at the edge is cheaper than every backend server doing it — and it's safe specifically because the inner hop stays inside a network the public internet can't reach at all (the private IP ranges and firewall/NAT concepts from earlier lessons are exactly what make that boundary real, not just assumed).

A page loaded over HTTPS that tries to load a resource (a script, an image) over plain HTTP breaks the security guarantee for the whole page — an attacker could tamper with that one HTTP resource even though everything else is protected. Browsers block this outright (or at minimum warn loudly), which is the actual mechanism behind "mixed content" errors developers hit when migrating a site to HTTPS but forgetting one hardcoded http:// asset URL.