Every browser in the world shows you a padlock when a site is encrypted. Millions of people were taught that padlock means safe. In 2024, more than 85% of phishing sites displayed that same padlock — fully encrypted, fully verified, completely malicious.

Encryption didn't fail. It worked exactly as designed. That's the misunderstanding worth fixing.

Encryption is the most important concept in digital security — and one of the most consistently misunderstood. It underpins every secure login, every private message, every online payment, and every corporate VPN. The entire architecture of internet trust is built on top of it. Which means that when people have a fundamentally wrong mental model of what encryption does, they make consistently wrong decisions about what they think is protected and what isn't.

This isn't a beginner problem. Developers ship applications assuming encryption solves problems it was never designed to solve. Security teams invest heavily in encrypted channels while leaving the endpoints wide open. Executives read "all data is encrypted in transit" in a vendor report and stop asking questions. The confusion runs deep, and the consequences are real.

The assumption is simple and nearly universal: encryption means secure. The padlock appears, the URL starts with HTTPS, and the mental model kicks in — this connection is protected, my data is safe, I can trust this. The padlock became a shorthand for safety so effectively that major browsers and security campaigns spent years training the public to look for it before entering sensitive information.

The assumption mistakes the channel for the destination. Encryption protects the road. It says nothing about where the road leads.

When attackers realized the public had been trained to trust the padlock, they did the logical thing — they started using it too. Getting a valid SSL certificate to make a site display HTTPS costs nothing and takes minutes. The certificate authority issuing it doesn't verify whether the site is legitimate. It only verifies that the person requesting the certificate controls that domain. A phishing site at a domain designed to look like your bank's URL gets the same padlock as your actual bank. The padlock was never a promise about the site. It was only ever a promise about the pipe.

Here's what encryption actually is, stripped to first principles. When you send data across the internet without encryption, that data travels as readable text — any device it passes through can read it. Your internet service provider, network operators, anyone running a packet capture on a shared network — all of them can see the raw content. Encryption converts that readable data into scrambled ciphertext using a mathematical key. Without the matching key, the ciphertext is meaningless noise. With it, the original data is perfectly recovered. That's the entire mechanism.

HTTPS specifically does this for the connection between your browser and the server you're talking to. It means nobody intercepting traffic between you and that server can read what's being transmitted. Your login credentials aren't visible to your ISP. Someone running a packet sniffer on the same coffee shop WiFi can see you're communicating with a server, but not what you're sending. This is genuinely valuable protection and the web is meaningfully safer for it. The mistake is in what people believe that protection extends to.

The exact boundary

Encryption protects data in motion — while it travels between two points. The moment data arrives at its destination and gets decrypted, encryption's job is finished. What happens next is completely outside its scope.

This boundary is where most of the real-world damage happens. A database storing your decrypted personal information gets breached — encryption of the transit channel didn't help. A server receiving your encrypted password decrypts it to check it against a stored hash — at that moment, if the server is compromised, the attacker has your password in plaintext regardless of how strong the encryption was in transit. Malware on your device reads your data before it ever gets encrypted to send anywhere. End-to-end encryption addresses some of this by keeping data encrypted all the way from sender to recipient, never decrypted in the middle — but even that has limits at the endpoints where data must ultimately be read by a human or an application.

The mental model worth building is this: encryption is a transport guarantee, not a trust guarantee. It answers one specific question — can someone intercept and read this data while it's moving? — and it answers that question well. It answers nothing about whether the destination is legitimate, whether the server at the other end is secure, whether the application handling your data is trustworthy, or whether your device is compromised. Those are separate questions requiring separate answers.

Once you see encryption this way, the padlock stops being a comfort signal and starts being a narrow technical fact. The right question isn't "is this encrypted?" It's "what exactly does this encryption protect, where does that protection end, and what am I trusting beyond that boundary?" Security decisions made with that question in mind are almost always better than ones made by looking for a padlock.

The padlock was never a promise about the destination — it was a promise about the pipe. Understanding that distinction won't make you paranoid. It will make you precise. And precision is what separates people who think clearly about security from people who feel safe while being wrong about why. The next time you see that padlock, you'll know exactly what it's telling you and exactly what it isn't. That's a more useful thing to carry than blind trust in a small green icon.

This week's question

Before reading this, what did you actually believe the padlock meant — and has anyone in your organization ever made a security decision based on that assumption? Hit reply. I read every response.

Think clearly,

— DJ Brar

SKBSEC | SKB Decoded  ·  www.skbsec.com