From HTTP To HTTPS

To understand what HTTPS adds, we first have to know what HTTP is missing. Let's follow a single request from a laptop in a coffee shop to a server in Frankfurt.

A Plain HTTP Request — In The Clear

Maria types http://example.com/login into her browser. She enters her username maria@email.com and password Sunshine2026. She clicks submit.

Here's what leaves her laptop, byte for byte:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

email=maria%40email.com&password=Sunshine2026

That's it. Plain text. Anyone who can see her network traffic — the coffee shop owner, anyone on the same Wi-Fi, every router between her and Frankfurt, her ISP, the ISP's government — can read it as easily as you just did.

Worse, anyone in the middle can also change the request. They can swap example.com for evil.com, modify the password, inject scripts into the response, replace the page entirely. HTTP has no defense against any of this.

The Same Request Over HTTPS

Maria adds an "S" and tries again: https://example.com/login. Same form, same submit button.

Here's what leaves her laptop now:

17 03 03 00 40 a3 9f b2 c1 0e 7d 88 e4 31 6a f5
2c 19 88 d7 8b 5e f3 90 4c b1 a2 7e 64 d5 12 38
... (encrypted gibberish for 1,400 more bytes)

The coffee shop owner sees only encrypted bytes. The ISP sees encrypted bytes. Anyone capturing the wire sees encrypted bytes. The server in Frankfurt decrypts it back into Maria's password, processes the login, encrypts the response, and sends it home.

What Actually Changed?

HTTPS is just HTTP wrapped in a TLS tunnel. The HTTP itself is identical. The verbs (GET, POST), the headers, the body — none of that changes. What changes is that before any HTTP byte leaves the laptop, it gets sealed in an encrypted envelope. The envelope is TLS.

You can picture the stack like this:

• Your app sends an HTTP request;
• TLS wraps it in an encrypted envelope;
• TCP delivers the envelope reliably;
• IP routes it across the internet;
• The server reverses the process.

The HTTP layer never knows TLS exists. The TCP layer never knows what's inside. Each layer does its job and ignores the rest. This is why "adding HTTPS" to a website doesn't require rewriting the app — you just put a TLS layer in front.

The Port Difference — 80 vs 443

HTTP runs on port 80. HTTPS runs on port 443. When Maria types https://, her browser opens a TCP connection to port 443 instead of port 80. That's the only thing that changes at the transport layer. The server listening on 443 is configured to speak TLS first, then plain HTTP inside the TLS tunnel.

Why You Can't "Just" Encrypt Everything

A natural question: if encryption is good, why isn't it default everywhere — not just on HTTPS but on every protocol? Three reasons:

• Encryption has a CPU cost, though on modern hardware this is tiny;
• It requires key exchange, which is a hard problem we'll spend the next several chapters on;
• It requires authentication — encrypting traffic to an attacker is no better than not encrypting at all.

TLS solves all three. The clever bits are in how it solves them.

The Hidden Cost of HTTP Today

In 2026, modern browsers actively punish HTTP. Chrome marks http:// pages as "Not Secure" in red. Search engines downrank them. Most HTML5 features (geolocation, camera access, service workers, HTTP/2, HTTP/3) refuse to work over plain HTTP. Calling a site "production" without HTTPS is now closer to a configuration error than a choice.

Next chapter, we'll look inside the encrypted envelope and answer the question every cryptography student trips over: why does TLS use two completely different kinds of encryption at the same time?