“As long as it’s HTTPS, you’re safe” ── you hear this everywhere once you start learning how the internet works. But how true is it, really? And the opposite case: that warning you sometimes see, “Your connection to this site is not secure” ── what exactly is it saying isn’t secure? These two questions are actually two sides of the same mechanism. If any of the following sounds familiar, keep reading.
- You’ve heard “HTTPS means safe” but don’t know how far to trust it
- You’ve seen the “Not secure” warning but can’t explain what the actual danger is
- You look at the lock icon in the address bar every day, yet you’d stumble if asked what it means
- Encryption, certificates, certificate authorities… you know the words, but not what each one is actually for
This article makes two promises. ① No math ── the only tools we’ll use are a “secret box”, a “padlock”, and an “ID card”. ② We won’t stop at how it works: we’ll draw the exact line between what the lock icon protects and what it doesn’t.
| Question | Where it’s answered |
|---|---|
| What makes HTTP dangerous? | §1 |
| How do you build a box nobody can read? | §2 |
| How do you know the other side is genuine? | §3 |
| What happens behind the scenes at the moment of connecting? | §4 |
| How true is “HTTPS means safe”? | §5 |
| What should I do when a warning page appears? | FAQ Q2 |
In our series recap, What happens between typing a URL and the page appearing, we described HTTPS traffic as a “sealed, encrypted envelope”. In this article, we find out what that seal really is.
1. What Exactly Isn’t Protected in an “Unprotected” Connection ── Your Password, Sent in a Form Anyone Can Read
1-1. An HTTP package is a postcard, and everyone along the route can read it
As we saw in the series recap, a request you send to a website leaves your home router, exits your town (your network), and gets relayed from town to town dozens of times before reaching the server (→ What happens between typing a URL and the page appearing).
Here’s the part that matters: you and the website are not the only two participants in this journey. Whoever is on the same Wi-Fi as you, the operator of the coffee shop’s free hotspot, the routers in every town along the way ── your package passes through a lot of hands and machines.
An http:// connection (no S) makes this journey on a postcard. The destination, the sender, and the message itself are all written right on the surface. That means anyone along the route who cares to look can read the password you typed and the contents of the pages you’re viewing, exactly as they are. The “Not secure” warning means precisely this: “You’re about to send a postcard. Are you sure?”
1-2. Reading is only part of it ── the three threats
Sorting out what’s wrong with a postcard, the danger comes in three flavors.
- Eavesdropping ── someone along the route reads the contents. Passwords, card numbers, and browsing details leak
- Impersonation ── a fake site claims “we’re your bank”, and you send your data believing it’s real
- Tampering ── someone along the route swaps the contents. If the “account number to wire to” gets rewritten, you’d never notice
Postcard (HTTP) vs secret box (HTTPS) ── what the route can see
HTTP (postcard)
You ── postcard ──> Wi-Fi neighbors, town routers, checkpoints… ──> Site
△ Everyone can read it / it can be swapped / no proof who's on the other end
HTTPS (secret box)
You ── [box] ─────> Wi-Fi neighbors, town routers, checkpoints… ──> Site
△ Only the "destination" is visible
Contents unreadable / swapping breaks the seal / identity verified by ID card
The S in HTTPS (Secure) is a service that blocks all three at once. It puts the conversation in a secret box (against eavesdropping), checks the other side’s ID card (against impersonation), and applies a tamper-evident seal so any swap along the way becomes obvious (against tampering). Starting in §2 we’ll see how the box is built ── but there’s a puzzle hiding right at the start: how do you share the key to the box with the other side in the first place?
2. How to Build the Secret Box ── Handing Out Open Padlocks (Public-Key Cryptography)
2-1. The key-distribution problem ── you need a key to send a key
“Lock the box and send it” is easy to say. But think about it: you and the website have never met. How do you share the key to the box (the secret code for encryption)?
Send the key itself? ── If the key travels by postcard, anyone along the route can copy it. And a copied key opens the box, which defeats the whole point. “To send a key safely, you need a secure channel first. To build a secure channel, you need a key.” This circular trap is called the key-distribution problem, and it stumped cryptographers for a very long time.
2-2. The invention: hand out open padlocks ── anyone may snap one shut, but only the owner can open it
The invention that broke the circle is public-key cryptography. In metaphor, it works like this.
The website hands out open padlocks to anyone who wants one. Anyone can snap a padlock shut ── but once it clicks, only the website, holding the matching key (the private key), can open it again. It doesn’t matter if the padlock itself gets copied: you can’t make a key out of a padlock.
You take the padlock the site gave you, snap it onto your box, and send the box back. Whoever handles that box along the way, they can’t open it. The key never traveled across the network, and yet a secure box now exists ── the key-distribution problem, solved.
The padlock round trip ── how a secret box works without ever sending a key
1. Site ──hands out an "open padlock"──> You △ The padlock may be seen by anyone
2. You ── put a secret code in the box, snap the padlock shut ──> Site
△ Nobody en route can open it (only the site holds the key)
3. Site ── opens it with the matching private key, takes out the secret code
4. After ── both sides use the shared code for fast boxes, back and forth △ The real conversation starts here
One practical note: the padlock method (public-key cryptography) is secure, but the computation is heavy and slow. So real HTTPS works in two stages ── the padlock is used for exactly one round trip, just to deliver a “secret code (shared key)“, and from then on the conversation switches to fast boxes locked with that code (symmetric encryption). One heavy safe to deliver a single key, then ordinary lockboxes at full speed ── a division of labor.
“Encryption alone means safe” ── not quite. Everything so far guarantees that only whoever handed out the padlock can open the box. But whether that someone is your actual bank, or an impostor claiming to be your bank, the box mechanism alone cannot tell you. Impostors can hand out padlocks too ── and that’s §3, the other half of what the lock icon means.
3. Is the Other Side Genuine? ── ID Cards (Certificates) and the Issuing Office (Certificate Authority)
3-1. Fake sites can hand out padlocks too
Recall threat ② from §1, impersonation. If a pixel-perfect fake site says “We’re your bank ── here’s our padlock”, you’ll snap the impostor’s padlock onto your box and send your precious secret code straight to the impostor. The box works perfectly, and delivers perfectly to the wrong person ── encryption by itself is helpless against impersonation.
3-2. The server certificate ── an ID card stamped by the issuing office
So HTTPS made one more thing mandatory: every padlock must come with an ID card. This is the server certificate. The certificate says “this padlock belongs to the owner of example.com“, and it carries the stamp of an issuing office (a certificate authority, or CA). A CA is one of a small number of trusted organizations in the world that verify “this party really owns this domain” before issuing a certificate.
Your browser ships with a built-in list of stamps from trustworthy issuing offices. When you connect to a site, the browser first receives the ID card and verifies it: is the stamp genuine, has it expired, and does the domain name written on it match the site you’re trying to reach? Only after everything passes does the browser accept the padlock and start the box exchange ── the lock icon in your address bar is the sign that both things are in place: “secret box” plus “ID verified”.
When your browser stops you with a full-screen red warning, it’s because this verification failed. The ID card has expired, the stamp isn’t trusted, the name doesn’t match ── the reasons vary, but the meaning is always the same: “I cannot confirm who this is, so no box should be built.“
An ID card proves “this party owns this domain” ── and nothing more. It does not prove “this party is honest“. A scammer can perfectly well get a legitimate certificate for a domain registered in their own name ── and this one fact leads straight to §5, the things the lock icon doesn’t protect.
4. What Happens in the Split Second of Connecting ── From the Handshake to the Box Exchange
4-1. Where it fits into the journey ── the handshake
Let’s lay this article’s toolkit over the journey from the series recap. You type a URL, the phone book (DNS) looks up the address, and a route forms for your package to leave town and reach the server. HTTPS steps in right after that ── before the first real package is sent, the two sides go through a short ritual called the handshake.
- 1HelloBrowser: “I’d like to talk in secret boxes. Here are the lock types I can use.”
- 2ID checkThe site presents its certificate and padlock. The browser verifies the issuing office’s stamp, the expiry date, and the name (§3).
- 3Sharing the secret codeThe padlocked box safely delivers the secret code (the shared key) (§2).
- 4Boxes start flowingEvery request and response from here on travels inside fast boxes locked with the shared code.
These four steps finish in an instant you can’t even feel ── roughly a tenth of a second or less. Everything you do while reading the page happens inside the boxes of step 4.
4-2. What checkpoints can and cannot see ── answering the recap’s FAQ
The series recap’s FAQ asked, “Can anyone read the package’s contents along the way?” and answered, “only the address is readable”. Now we can explain why.
The routers in each town, the checkpoint (firewall), the translation desk (NAT) ── they all read the destination label on the outside, because delivering the package requires it; they literally couldn’t deliver it otherwise (→ What happens without a firewall?). But the contents stay inside the secret box. “Who you’re talking to” is visible as part of routing the package; “what you’re saying” is visible to no one ── that is the precise picture of HTTPS. The only one who can open the box is the server at the end of the journey. What exactly that server is happens to be a fascinating topic of its own, and we’ll save it for another article.
5. There Are Things the Lock Icon Doesn’t Protect ── HTTPS Does Not Mean “Safe Site”
5-1. What it does protect, precisely ── the channel between you and the site
Putting it all together: what HTTPS protects is the channel between you and the site. The three threats from §1 ── eavesdropping, impersonation, and tampering along the route ── are genuinely blocked by the combination of secret box and ID card. Even on coffee-shop Wi-Fi, the odds of your password being skimmed in transit are now close to zero.
5-2. What it doesn’t protect ── beyond the channel, and outside it
So how true is “HTTPS means safe”? The line falls here: the channel is protected. What lies beyond the channel (the other party itself) and outside it (the destination information) is not.
| Protected ✅ | Not protected ❌ | |
|---|---|---|
| Eavesdropping en route | Contents stay in the box ── unreadable even on shared Wi-Fi | ── |
| Tampering en route | The tamper-evident seal exposes any swap | ── |
| Impersonation of the site | The ID card confirms who owns the domain | ── |
| The site’s honesty | ── | Scam sites get legitimate certificates too. Phishing sites with lock icons are completely routine |
| Hiding the destination | ── | “Which site you’re talking to” remains visible along the route |
| Your data after arrival | ── | How the site handles your information is outside the box’s jurisdiction |
The fourth row is the one that matters most. “There’s a lock icon, so this must be my real bank” is wrong. The lock icon guarantees exactly one thing: “you have a secret-box channel with the owner of the domain shown in the address bar”. If the domain name itself is fake (say, a near-identical misspelling of the real one), the box works flawlessly ── and connects you directly to a scammer. What you should check is not whether the lock icon is there, but whether the domain name is really the one you meant to visit.
5-3. Comparing coverage ── how VPN and DoH relate
For readers who’ve followed the series, here’s how the coverage maps line up. The VPN article touched on the question “if HTTPS exists, why do we need VPNs?” in a Tip ── HTTPS wraps “one channel between your browser and one site”, while a VPN wraps “all traffic leaving your PC, destination information included”. The coverage is one level wider. And there’s one more thing the journey in §4 left outside the box ── the query to the phone book (DNS). “Which name you looked up” has traditionally traveled in the open, and the mechanism that puts it in a box too is DoH, introduced in §6 of the DNS article.
Summary ── the Essence in 4 Lines
- HTTP is a postcard: everyone along the route can read it, swap it, or impersonate the recipient ── that’s what “Not secure” means
- The secret box (encryption): handing out open padlocks creates a “box only the owner can open” without ever sending a key
- The ID card (certificate): the issuing office’s (CA’s) stamp confirms “this party owns this domain” before any box exchange ── lock icon = box + ID card
- The line: only the channel is protected. The site’s honesty, the destination, and your data after arrival are not ── check the domain name, not just the lock icon
To keep filling in the map of the invisible machinery: the full journey is in the series recap, the checkpoint on the route is the firewall article, the wider box is the VPN article, and the name lookup is the DNS article. And the “membership card” that travels inside the box is the subject of the cookies article.
FAQ
Q1. If the lock icon is there, is it safe to enter personal information?
A. The precise answer is “the channel is safe; the other party is a separate question” (§5). The information you enter is very unlikely to be skimmed in transit. But if the site receiving it is itself a scam, the box can’t help you. Before entering anything, the thing to check is not the lock icon but whether the domain name in the address bar is really the one you intended (and not a look-alike misspelling). Opening sites from your own bookmarks or the official app is the strongest habit you can build.
Q2. Is a site that shows “Not secure” dangerous even just to look at?
A. If you’re only looking, the practical harm is limited ── what you viewed is visible along the route, and the displayed content could in principle be swapped. But never type anything into it: that would be writing your password on a postcard (§1). For an old informational site that triggers the warning, “read only, enter nothing, download nothing” is a perfectly reasonable rule ── no need to panic.
Q3. The web used to be full of HTTP sites ── why is almost everything HTTPS now?
A. Two forces worked at once. ① Free certificate issuance arrived, and the cost of the ID card (money and effort) collapsed. ② Browsers changed policy and began warning visitors about non-HTTPS sites, so staying on HTTP meant your visitors saw “Not secure” next to your name. It’s less that the web became safer, and more that postcards stopped being acceptable.
Q4. Can my company’s network admin, or a VPN provider, see inside my HTTPS traffic?
A. As a rule, no ── only the destination server can open the box, and that holds inside a company network and inside a VPN tunnel alike. What admins can see is the destination information: “who talked to which site, and when” (§4-2). There is one exception: on a company-issued PC, traffic may pass through an inspection relay that opens each box and re-locks it (made possible by pre-installing the company’s own “issuing-office stamp” on the machine). On company devices, the safe assumption is that the contents can be seen too.
Q5. What is “port 443”, which keeps coming up around HTTPS?
A. It’s a “counter number” at the server’s building. Postcards (HTTP) go to counter 80, secret boxes (HTTPS) go to counter 443 ── separate reception desks. When the checkpoint (firewall) enforces rules like “only let traffic for counter 443 through”, this is the number it’s looking at. Counter numbers (port numbers) are a rich enough topic for an article of their own, and we plan to cover them in the future.
Leave a Reply