Chapter 2: Names, lost packets, and trust
What the padlock promises
What HTTPS protects, how your phone knows it reached the real site, and what the padlock can't tell you.
Your packets pass through a lot of hands on the way to a server. There's the coffee shop Wi-Fi, your provider, and every network in between. Without encryption, any of them could read what you send, or change it on the way.
HTTPS fixes that. It's ordinary HTTP wrapped in TLS, Transport Layer Security. The padlock or similar icon in your address bar means TLS is on.
Two problems at once
Encryption alone isn't enough. A perfectly secret channel to an impostor protects nothing. So TLS has to settle who you're talking to before it settles who can listen.
First, identity. When you connect, the server presents a certificate, a signed statement saying that a particular key belongs to wikipedia.org. The signature comes from a certificate authority, one of a list of organizations your phone already trusts because its maker shipped that list with the software. Before signing, the authority checks that whoever asked really controls the domain. If the certificate doesn't match the name you typed, your browser stops you with a full-page warning.
Second, privacy. Your phone and the server agree on a fresh secret key using math that works even while strangers watch every message of the exchange. An eavesdropper sees the whole conversation and still can't work out the key. From then on, everything is encrypted, and any tampering shows up as an error instead of a changed page.
Step through the public key shares and identity checks. Try a wrong-domain certificate and see why the request must stop.
What the padlock does promise
- You're connected to a server that controls the domain in the address bar.
- Nobody between you and that server can read what you send or receive.
- Nobody in between can quietly change it.
What it doesn't promise
The padlock says nothing about whether a site is honest. A scam site at yourbank-secure-login.com can get a valid certificate in minutes, because the authority only checks that the scammer controls yourbank-secure-login.com, and they do. The padlock proves you reached that address. It can't tell you it's the address you meant. Read the domain, not the lock.
It also doesn't hide everything. Your network can usually still tell which site you're connecting to, because the server's address, and often its name, sit outside the encryption. Watchers can see how much data moves and when. What they can't see is which pages you read or what you typed.
And the protection ends at the server. Once your data arrives, TLS has done its job. What the company does with it next is a question for its privacy policy, not for the padlock.
Where you've been
That's the whole trip. A name becomes a number, a message becomes packets, routers pass them hop by hop, TCP or QUIC repairs what gets lost, and TLS keeps the conversation private. Next time a page hangs, you'll have a decent guess which part is stuck.
Rabbit holes
Questions worth chasing. In Learnfold, tap one and your tutor answers it as a new lesson in your course.
- How can two computers agree on a secret key while strangers watch every message?
- What happens when a certificate authority gets hacked or signs a certificate it shouldn't?
- Is it safe to log in to my bank on public Wi-Fi if the padlock is showing?