HTTP vs HTTPS: What the S Really Does

What is HTTP?

First, HTTP. The Hypertext Transfer Protocol is the language browsers and servers use. It's simple: the client sends a request, and the server sends back a response.

A request has a method, like GET to read or POST to send data, a path, and headers: extra details like the host, the browser, and cookies.

The response has a status code, headers, and a body. 200 means OK, 3xx means it moved, 4xx means you made a mistake, like 404 not found, and 5xx means the server failed.

One key property: HTTP is stateless. Each request stands alone, and the server doesn't remember the last one. That's why cookies and tokens exist: they carry who you are, on every request.

GET /balance HTTP/1.1
Host: bank.com
Cookie: session=8f3a…
Accept: text/html

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: …

<html>Balance: 42,000</html>

The problem

Here's the problem. Plain HTTP is plain text. Your data passes through routers, the café Wi-Fi, your internet provider. Anyone along that path can read it: passwords, cookies, everything.

There are three risks. Eavesdropping: someone reads it. Tampering: someone changes it, for example injecting ads or malware into a page. And impersonation: a fake server pretends to be your bank.

The fix

HTTPS fixes all three. It's the same HTTP, but wrapped inside TLS, Transport Layer Security. TLS gives encryption, so nobody can read it. Integrity, so nobody can change it unnoticed. And authentication, so you know it's really your bank.

Keys, briefly

To understand TLS, you need two ideas. Symmetric encryption uses one shared key: it's fast, but how do two strangers agree on a key without anyone overhearing? Asymmetric encryption uses a key pair: a public key that anyone can use, and a private key only the owner has.

TLS handshake

TLS uses both. Here's the handshake, in TLS 1.3. Step one: the browser says hello. It lists the versions and ciphers it supports, and sends its half of a key exchange.

Step two: the server replies with its choices, its half of the key exchange, and its certificate: a document that says, this public key belongs to bank.com.

Step three: the browser checks the certificate. Is it signed by a certificate authority the browser already trusts? Does the name match bank.com? Has it expired? If anything is wrong, you see a big warning page.

Trust flows down a chain. Your browser and operating system ship with a list of trusted root authorities. A root signs an intermediate, and the intermediate signs the site's certificate. Services like Let's Encrypt issue these for free.

Step four: from the key exchange, both sides compute the same secret session key, without ever sending it across the network. Someone watching sees the exchange, but can't work out the key.

After the handshake

From now on, every request and response is encrypted with that fast symmetric key. Someone on the café Wi-Fi sees only noise. TLS 1.3 does all of this in a single round trip.

One subtle point. HTTPS hides the path, headers, cookies and body. But the network can still see which IP you're talking to, usually the domain name, and roughly how much data moves.

Performance

Is HTTPS slow? Not any more. The handshake costs about one round trip, or none when a session is resumed, and the encryption cost on modern chips is tiny. Newer HTTP versions require it, and browsers mark plain HTTP as not secure.

In system design

In system design, you'll hear TLS termination. Usually the load balancer or reverse proxy holds the certificate and decrypts traffic, then talks to the servers behind it, either over plain HTTP inside a private network, or re-encrypted for extra security.