Why HTTPS?

Before learning how HTTPS works, it's worth being precise about what problem it solves. HTTPS is just HTTP carried over TLS (Transport Layer Security) — the application protocol is unchanged; what changes is that everything travels through an encrypted, authenticated channel instead of as open text. This chapter sets up the threat model the rest of the course answers.

Plain HTTP Travels in the Clear

An HTTP request is plain text sent over TCP. Every device between your computer and the server — your router, your ISP, every network hop, the coffee-shop Wi-Fi access point — handles those bytes, and with plain HTTP they can read every one of them. A login request looks literally like this on the wire:

There is no encryption, no signature, no proof of who sent it or who received it. Anyone positioned on the path sees the URL, the headers, the cookies, and the body — including that password in the clear. This is the default behaviour of HTTP, and it is the baseline HTTPS exists to fix.

Three Things Can Go Wrong

The weaknesses of plain HTTP fall into three distinct categories. Keeping them separate matters, because HTTPS addresses each one with a different mechanism (which later chapters cover):

When all three are combined by an attacker sitting between the two parties — reading, modifying, and impersonating at once — it's called a man-in-the-middle (MITM) attack. The MITM is the central adversary the whole TLS design is built to defeat.

The Three Guarantees HTTPS Provides

Each threat is answered by a corresponding guarantee. These three words are the spine of the entire course — every mechanism you'll learn exists to deliver one of them:

Notice the mapping is one-to-one: confidentiality ↔ eavesdropping, integrity ↔ tampering, authentication ↔ impersonation. A common beginner mistake is to think "HTTPS = encryption" and stop there — but encryption alone (confidentiality) would still let you have a perfectly private conversation with an impostor. Authentication is what makes the encryption meaningful, by guaranteeing who you've established the private channel with.

What HTTPS Does and Doesn't Protect

A precise mental model also means knowing the limits. HTTPS protects data in transit between the two endpoints — and only that:

• Protected: the request/response bodies, headers, cookies, and the specific path & query string — all unreadable and unmodifiable to anyone on the network path.
• Still visible to the network: the domain name you're connecting to (via DNS and the TLS handshake's SNI field) and the rough size/timing of traffic. Observers know you visited example.com, just not what you did there.
• Not HTTPS's job at all: security at the endpoints — a hacked server, malware on your machine, a phishing site with its own valid certificate, or a weak password. HTTPS secures the pipe, not what's at either end of it.

The Cost Is Now Negligible

Historically HTTPS was seen as slow and expensive (CPU cost, paid certificates), which is why plain HTTP lingered. That's no longer true: modern CPUs handle TLS with minimal overhead, TLS 1.3 cut the handshake cost dramatically (Chapter 7), and certificates are now free and automatable via Let's Encrypt (Chapter 9). Today HTTPS is the default expectation — browsers mark plain HTTP pages as "Not Secure," and many web features (HTTP/2, service workers, geolocation) simply refuse to run without it. There's no longer a real argument for plaintext HTTP on the public web.

Hands-On Exercises