HTTP & HTTPS: from postcards to sealed envelopes

Once upon a time — and not even that long ago — a huge part of the Web ran without encryption. No hackers jumping out of wardrobes, no dramatic soundtrack. That was simply everyday Internet life. To understand what changed, let's visit a post office whose manager bought four million postcards.

Welcome to the post office where everything is in plain sight

A small town had a busy post office. Residents sent messages to friends, shops, public offices and banks. Everything worked nicely. There was just one minor detail: every message was written on a postcard. No envelopes.

A customer approached the counter.

— Hello, I'd like to send a message to my bank.
— Certainly. Hand over the postcard.
— Here you are.
— “Dear bank, my password is...” Ooooh, interesting!
— EXCUSE ME, WHY ARE YOU READING THAT?!
— Because it's written here.
— BUT IT'S PRIVATE!
— Then why did you write it on a postcard?!
— BECAUSE YOU DON'T OFFER ANYTHING ELSE!
— Exactly. Next, please!

🤣🤣

That's a useful way to picture ordinary HTTP — Hypertext Transfer Protocol. HTTP lets a browser request a page, picture or other resource and receive a response from a server. Traditional HTTP connections, however, do not encrypt their contents. Someone with access to data along the route may read it and, under certain conditions, alter it.

Of course, this does not mean everyone in the world can see every message. Not every passer-by gets to handle every postcard. The point is that anyone who can access a postcard can read its contents without opening anything.

How does HTTP work? One website, please!

The browser walks up to the counter.

— Hello. One homepage, please.
— Which one?
— example.com.
— Just a moment.
— Thank you.
— There you go. Your page.
— Is that it?
— What else were you expecting? A brass band?

At its simplest, HTTP is request and response. The browser asks for something; the server sends an answer. You don't need to learn every technical detail to understand the essential idea.

For example, a browser might send GET /, meaning “please send the homepage”, and the server replies with 200 OK and the page contents. HTTP commands aren't the problem. The problem with ordinary unprotected HTTP is that the connection has no encryption.

What if we started using envelopes?

One day, the post office hired an ambitious new employee.

— Boss, I've got a suggestion.
— Go on.
— Could we send messages in sealed envelopes?
— IN WHAT?!
— Envelopes. So strangers can't read the contents.
— But we've been using postcards for years!
— I know. Anyone with access can read them.
— THEN THEY SHOULDN'T READ THEM!
— Security can't depend entirely on strangers being polite.
— What if we write “PLEASE DON'T READ” on the postcard?
— That won't work.
— EVEN IN CAPITAL LETTERS?!
— Even then.
— DAMN. WE'LL HAVE TO BUY ENVELOPES.

🤣🤣

Enter HTTPS — Hypertext Transfer Protocol Secure. And here's the most important point: HTTPS still uses HTTP! Browsers still ask, servers still respond. The difference is that the HTTP conversation is protected by TLS.

With TLS, people along the route shouldn't be able to read correctly protected traffic or secretly change its contents. That's a major improvement, not some obstacle invented by bored administrators.

Why didn't we use envelopes from the start?

HTTPS isn't a recent invention. Secure Web connections began developing back in the 1990s. Yet many ordinary websites used HTTP for years. HTTPS was especially associated with logins, payments and online banking.

There were practical reasons: encryption used more processing power, obtaining and renewing certificates was more work, and configuration was often harder than it is today. Over time computers became faster, tools matured, certificates and automatic renewal became more accessible, and browsers started strongly warning users about unprotected sites.

Meanwhile, the post office holds a management meeting.

— Boss, more and more offices are switching to envelopes!
— WHAT ABOUT OUR POSTCARD WAREHOUSE?!
— We could sell them to tourists.
— WE HAVE FOUR MILLION OF THEM!
— Perhaps a special offer?
— WHAT SORT?!
— “Buy a postcard, get an envelope free”.
— YOU'RE FIRED!

🤣

Today HTTPS is the standard choice for public websites. This doesn't mean everybody in the past was foolish. Technology and expectations for security have evolved.

An envelope is not an invisibility cloak

The manager decides to test the new system. He puts a letter in an envelope and hands it to the postman.

— What's inside?
— I don't know.
— Excellent! Where are you delivering it?
— To the bank.
— HOW DO YOU KNOW?!
— The address is on the envelope.
— THEN CROSS IT OUT!
— But then I won't know where to deliver it!
— CAN'T YOU JUST GUESS?!

🤣🤣

HTTPS protects HTTP contents, but it doesn't automatically hide every detail of the connection. An observer may still see IP addresses, ports, timing and approximate traffic volume. In some configurations the website's name may also be visible through DNS requests or information exchanged while establishing TLS. Technologies exist to reduce some of those disclosures, but the letters HTTPS do not mean complete anonymity.

The analogy is simple: an envelope protects the letter, but the post office still needs information to deliver it.

Somebody changed the postcard!

A customer asks the town office for its opening hours. The office writes: “Open from 8 a.m. to 4 p.m.” Someone able to interfere with delivery changes the reply to: “Open from 3 a.m. to 4 a.m. Please bring your own chair.”

At three in the morning, the customer appears outside the building.

— GOOD MORNING! I'M HERE!
— WHAT DO YOU WANT AT THIS HOUR?! — shouts the security guard.
— I'VE COME TO THE OFFICE!
— AT THREE IN THE MORNING?!
— THAT'S WHAT THE MESSAGE SAID!
— WHERE?!
— ON THE POSTCARD!
— BOSS! SOMEONE'S TAMPERING WITH OUR MAIL AGAIN!

🤣🤣

HTTPS provides not only confidentiality but also integrity for protected traffic. Somebody along the route shouldn't be able to modify a message without the recipient detecting the interference. Ordinary HTTP without TLS provides no such protection at the connection level.

How do we recognise the right recipient?

The envelopes worked beautifully until a customer asked an awkward question.

— How do I know I'm sending this to my real bank?
— Because the building has a sign saying “BANK”.
— And what if a fraudster puts the same sign on another building?
— ...
— Exactly.
— BOSS! WE ALSO HAVE TO VERIFY WHO RECEIVES THESE ENVELOPES!
— WILL THERE EVER BE PEACE IN THIS OFFICE?!

HTTPS also uses TLS mechanisms to verify the server's identity, including its certificate. The browser checks, among other things, whether the certificate matches the website's domain name and is trusted. This helps us protect the conversation and reduces the risk of speaking to the wrong server.

But certificates, keys, certification authorities and chains of trust deserve their own story: “SSL/TLS Certificates: how do you know who you're talking to?” Expect paperwork, rubber stamps and extremely serious-looking officials.

HTTP, HTTPS, ports and redirects

— Boss, where do ordinary postcards go?
— Counter 80!
— And sealed envelopes?
— Counter 443!
— Why those numbers?
— That's the convention.
— What if somebody sets a different one?
— Then it's another counter. Just make sure the sender knows where to go.

HTTP normally uses port 80, while HTTPS normally uses 443, although services can use other ports too. A web server often redirects visitors from http:// to https://. That's useful, but only after a protected connection is established does TLS secure the HTTP traffic. A redirect cannot retroactively make an earlier unencrypted request secret.

HSTS can help browsers avoid later insecure connections to a site. For first visits, inclusion in an HSTS preload list can also help protect against that initial insecure attempt.

HTTP hasn't disappeared. Its journey has changed

— So HTTP no longer exists? — asks the manager.
— Of course it exists.
— THEN WHY DID WE BUY ENVELOPES?!
— Because HTTPS is still HTTP, protected by TLS.
— What about HTTP/2 and HTTP/3?
— Different versions of how HTTP requests and responses are exchanged.
— DO THEY ALSO NEED POSTCARDS?!
— No, boss. Please put the stationery catalogue away.

HTTP still describes communication between browsers and servers. Modern websites use different versions, including HTTP/1.1, HTTP/2 and HTTP/3. In browsers, these are predominantly used over secure connections; HTTP/3 uses QUIC with security based on TLS 1.3. This is an evolution in transport, not a return to unprotected postcards.

Unencrypted HTTP can still appear in testing, on some local networks or between services with other protections. For a public website, HTTPS remains the sensible starting point.

Finale: the last postcard

After months of reorganisation, the post office was finally running smoothly. Messages arrived, correspondence was protected, and customers no longer needed reminders not to write passwords on open postcards.

The manager decided to celebrate.

— Gentlemen! Let's tell every customer about our new secure correspondence!
— Excellent, boss.
— I've written a beautiful announcement!
— Wonderful. Shall we use envelopes?
— NO! POSTCARDS! WE STILL HAVE THREE MILLION NINE HUNDRED THOUSAND LEFT!

🤣🤣🤣

The Internet Post Office reminds customers not to send private messages on unprotected postcards. The manager nevertheless requests that all remaining warehouse stock be used before the end of the year.