Series Part of Cybersecurity for Everyone · Episode 05 of 10
View 10-Part Syllabus →
Episode 05 · Web Cryptography & TLS Myths · September 28, 2026 · 6 min read

Why the Padlock Doesn't Mean a Website Is Safe

https:// parcel-redelivery.org TLS VALID ARMORED VAN ! Scammer Server Wrong Destination Connection: Securely Encrypted · Destination: Fake Website
Episode 05 HTTPS & TLS Phishing Tactics DV Certificates Domain Anatomy · 6 min read
💬 Feedback
11%
Correct Comprehension
Google study found only 11% correctly understood the lock icon
>95%
HTTPS Adoption
Chrome page loads on Windows using HTTPS; phishers use it too
DV Only
Domain Control Only
Certificates prove server control, not business honesty or safety

You get a text saying your parcel couldn't be delivered.

There's a link to rearrange the delivery and a small £1.49 fee to pay. You're actually waiting for a parcel, so the timing makes sense.

You tap the link.

The website opens normally. The delivery company's logo is there. The colours look familiar. Nothing seems broken or suspicious.

You hesitate for a second and check the address bar.

🔒 HTTPS · No browser warning · Looks secure

So you continue.

And that's exactly where one of the biggest misunderstandings about web security begins.

For years, we've been told:

“Look for the padlock before entering your details.”

That advice wasn't completely wrong. HTTPS is extremely important.

The problem is that many of us started believing the padlock meant something it never actually promised. We turned:

“This connection is protected.” → into: “This website is safe.”

Those are two very different things.

So, What Does HTTPS Actually Mean?

Let's keep this simple.

When you visit a website using HTTPS, your browser uses TLS — Transport Layer Security — to protect the communication between your browser and the website's server.

TLS mainly gives us three things: encryption, integrity, and authentication.

🔐 Encryption
Your information is protected from being read while travelling across the network.
🛡️ Integrity
Nobody can secretly tamper with or modify traffic on the wire without detection.
📜 Authentication
Your browser verifies the server holds the certificate associated with that specific domain name.

In normal language: your information is protected from simply being read while travelling across the network, someone shouldn't be able to secretly modify that traffic without detection, and your browser can authenticate the server associated with the domain and certificate you're connecting to.

That's important.

If you're signing into your bank, sending a private message, or entering payment information, you absolutely want that protection.

But HTTPS is protecting the connection.

It isn't sitting there asking:

  • Is this company honest?
  • Is this website a scam?
  • Should this person be trusted with your password?

That's not HTTPS's job. And that's the part people often miss.

Think About It Like an Armoured Van

Imagine you're sending a confidential document.

You put it inside an armoured delivery van. The doors are locked. Nobody on the road can open it. Nobody can secretly replace your document while it's travelling.

Perfect.

Except you've given the driver the wrong address.

The van securely delivers your confidential document... straight to a scammer.

Nothing went wrong with the van. The transport was secure. The destination was wrong.

HTTPS can work in much the same way.

You can have a properly encrypted connection to a phishing website. If you enter your password there, someone casually watching the network may not be able to read it.

But the phishing website can.

Of course it can. You sent the password to it.

That's the key idea: HTTPS can protect your connection to a website without making that website trustworthy.

THE TRANSPORT (HTTPS / TLS) 🔒 Armoured Van (Encrypted Wire) Locked doors · Eavesdroppers locked out Transport: Working 100% Correctly ✓ Data is shielded from open Wi-Fi sniffers. THE DESTINATION (WEBSITE) ⚠️ Scammer's Address Wrong recipient receives your document Destination: Untrustworthy Fraudster ✗ The scammer can read whatever was delivered.

Yes, a Phishing Website Can Have HTTPS

This still surprises people.

A phishing website can have HTTPS. It can have a valid TLS certificate. It can have a beautiful design. It can copy Microsoft's logo. It can look like your bank. It can look like a delivery company.

It can even look more professional than some legitimate websites. And it can still be completely fake.

Imagine you receive:

Microsoft Security Alert

“We've detected unusual activity on your account. Please verify your identity immediately.”

You click. The page looks familiar. Microsoft logo. Same colours. Email box. Password box. HTTPS. Everything feels normal.

But instead of being on:

microsoft.com

you're actually on something like:

microsoft-account-check.example

If you enter your password, HTTPS isn't going to save you.

In fact, HTTPS may be working perfectly. Your browser can establish an encrypted connection and securely send the information you entered to that server.

The problem is simple: the server belongs to the wrong person.

“But Doesn't HTTPS Need a Certificate?”

Yes. And this is where another misunderstanding starts.

People sometimes imagine that getting a certificate means somebody has inspected the website and decided:

Real company ✓
Trustworthy owner ✓
Safe content ✓
No malware ✓

That's not what a normal Domain Validation certificate, commonly called a DV certificate, is designed to tell you.

For domain validation, the important question is whether the applicant can demonstrate control of the domain. That's very different from proving that the person behind the domain is trustworthy.

Let's Encrypt explains this clearly in their research (The CA's Role in Fighting Phishing and Malware): a DV certificate establishes a relationship between a public key and a domain. It doesn't tell you about the website's reputation, the real-world identity of whoever operates it, or whether the site's content is safe.

So if a scammer controls a deceptive domain, they may still be able to obtain a legitimate certificate for that domain.

The certificate isn't saying: “This is Microsoft.”

It's helping establish: “You're communicating securely with the domain covered by this certificate.”

That's an important difference.

The Logo Is Easy to Copy

Here's something worth remembering: A logo proves almost nothing.

Neither does a familiar colour scheme.

A phishing page can copy images, fonts, wording and page layouts from the real website. Attackers don't need Microsoft's or a bank's permission to put their logo on a fake webpage.

What matters much more is where the page actually is.

Let's take this fictional address:

paypal.secure-payment.example

You might quickly notice the word paypal and assume everything is fine.

But in this example, paypal is only a subdomain.

The important domain is: secure-payment.example.

Whoever controls that domain could potentially create addresses such as:

  • paypal.secure-payment.example
  • amazon.secure-payment.example
  • microsoft.secure-payment.example

Seeing a familiar company name somewhere inside a long address doesn't mean that company owns the website. And attackers know most people aren't carefully analysing domain structure every time they click a link.

https:// paypal. secure-payment.example PROTOCOL Wire Encrypted SUBDOMAIN (TRICK) Bait to fool skimming eyes ACTUAL DESTINATION DOMAIN Owned by attacker · Controls full server
Phishing isn't really testing your intelligence. It's testing your attention.

That's why these attacks often work. Think about when you usually receive these messages:

  • You're working.
  • You're on the bus.
  • You're walking home.
  • You're watching something.
  • You're about to go to bed.

Then your phone buzzes:

“Your parcel couldn't be delivered.”
Or: “Payment failed.”
Or: “Someone has accessed your account.”
Or: “Verify your account within 30 minutes.”

Suddenly there's a problem. You want to fix it. You tap the link. The page looks right. HTTPS is there. You enter your details.

The attacker didn't need to fool you for an hour. They may only have needed your trust for twenty seconds.

That's why the urgency is often just as important as the fake website itself. The message keeps your attention on: “How do I fix this?” instead of: “Where exactly am I?”

Google Realised the Padlock Was Confusing People Too

This misunderstanding became big enough that Google changed Chrome's interface.

In 2023, the Chromium security team explained (An Update on the Lock Icon) that the lock icon was never intended to indicate that a website itself was trustworthy.

More interestingly, Google's research found that in a 2021 study, only 11% of participants correctly understood the precise meaning of the lock icon.

Chromium also pointed out that nearly all phishing sites use HTTPS.

Think about what that means. We spent years teaching people: Padlock = safe, while phishing sites were perfectly capable of displaying the padlock too.

So Chrome moved away from the traditional lock icon and replaced it with a more neutral controls-style tune icon.

And HTTPS wasn't removed because it had failed. Quite the opposite.

By 2023, Chromium reported that more than 95% of Chrome page loads on Windows were already using HTTPS. HTTPS had become normal. That's exactly what we wanted.

But when almost every website uses HTTPS — including malicious ones — HTTPS alone isn't a useful way to decide whether a website deserves your trust.

The Same Thing Applies to Downloads

Let's say you're searching for some software.

Maybe a PDF converter. A game. A video-editing tool. You find a website offering exactly what you need. It uses HTTPS.

Does that mean the download is safe?

No.

HTTPS protects the communication between you and the server. It doesn't inspect the intention of the person running that server.

If the server deliberately sends you a malicious file, that file can still arrive through an encrypted connection. The encryption isn't broken. It's doing exactly what it's supposed to do: protecting the data while it's travelling.

It just happens that the data being delivered is something you shouldn't have trusted in the first place.

Again, think about the armoured van: locking the doors protects what's being transported; it doesn't decide whether what's inside is safe.

“Wouldn't My Browser Just Warn Me?”

Sometimes it will.

Modern browsers have other security mechanisms designed to identify known phishing sites, malware, and dangerous downloads.

Companies can add even more layers: email filtering, DNS security, endpoint protection, web filtering, identity monitoring, and threat intelligence. All of that helps.

But none of it means every malicious website will be recognised instantly.

  • A phishing site can be brand new.
  • The domain might not have much reputation data yet.
  • It may not have been reported by any user or automated scanner.
  • Security providers may still be learning about it.

So these things can all be true at the exact same time:

• The website is brand new.
• The website uses HTTPS.
• The website looks completely professional.
• The website is completely malicious.

That's why “My browser didn't warn me” shouldn't automatically become “It must be safe.”

Now Look at the Same Situation From a SOC

For the person who clicked the link, the story might simply be:

“I received a Microsoft email, clicked the link and logged in.”

For a SOC (Security Operations Center) analyst, that's where the investigation starts.

The analyst may look at the email that delivered the link. Then the domain. Then DNS or web activity. Then the endpoint. Then identity events.

  • Maybe the organisation has never seen that domain before.
  • Maybe unusual authentication appears afterwards.
  • Maybe the user's account suddenly starts behaving differently.
  • Maybe there are other alerts around the same time.

One event alone might not prove much. But several events together can tell a completely different story.

That's why a SOC analyst isn't going to see HTTPS and think: “Okay, it's safe.”

The better question is: “HTTPS to where?”

Then: What happened before the connection? What happened afterwards? Does this domain make sense? Does this activity make sense for this user? Are other users visiting the same domain? Did the endpoint do anything unusual afterwards?

That's where security monitoring becomes useful. It's rarely one magical indicator telling you ATTACK. More often, it's several ordinary-looking pieces that become suspicious when you put them together.

Interactive Destination & URL Inspector

Test how address bars and SSL/TLS certificates behave across common phishing lures compared to legitimate destinations. Select a scenario or type an address to inspect:

🔍 Address Bar & TLS Reality Inspector

Click a scenario to see how deceptive websites exploit the HTTPS padlock:

So Does HTTPS Still Matter?

Absolutely.

The point of this article isn't: “HTTPS is useless.” That would be completely wrong.

HTTPS is essential to the modern web. TLS protects data while it's travelling across networks. It provides confidentiality and integrity and supports authentication of the server you're connecting to.

Without those protections, attackers positioned on a network could have much greater opportunities to read or manipulate web traffic.

So HTTPS matters. Certificates matter. Encryption matters.

The mistake is expecting them to answer a different question.

✓ What HTTPS Answers
“Is my connection to this domain protected from wiretapping and modification?”
✗ What HTTPS Does NOT Answer
“Should I trust the person or criminal syndicate behind this domain?”

So What Should You Actually Do?

You don't need to become a cybersecurity analyst every time you open a website. You don't need to inspect certificates or understand how a TLS handshake works.

Just change one habit:

The Single Most Effective Habit:

Before entering a password, payment information or sensitive personal details, look at where you actually are. Check the domain.

And be especially careful when you arrived through an unexpected email, text message or social-media message.

If your bank says there's a problem, you don't have to use the link they sent. Open your banking app yourself.

If Amazon says something is wrong with an order, open Amazon directly.

If Microsoft says there's suspicious activity, navigate to your Microsoft account yourself.

If a delivery company says your parcel couldn't be delivered, go to the company's official website or app and check your tracking there.

You're doing something very simple: removing the attacker's link from the equation.

Maybe We Need to Change the Old Advice

For years, we said: “Look for the padlock.”

Maybe the better advice today is: “Check the destination.”

Because this combination is completely possible:

HTTPS? Yes.
Valid certificate? Yes.
Professional-looking website? Yes.
Familiar company logo? Yes.
Legitimate website? No.

The padlock wasn't lying. HTTPS wasn't broken. The certificate wasn't necessarily fake. We were simply asking it the wrong question.

We looked at the padlock and asked: “Is this website safe?”

But the technology was answering something much narrower: “Your connection to this domain is protected.”

A protected connection can take you to your bank. It can take you to Microsoft. It can take you to your workplace. And it can take you straight to a phishing page.

So next time a website asks for your password, card details or personal information, don't stop checking because you see HTTPS. Ask yourself one more question:

Who am I securely connected to?

Because encryption can protect your information while it's travelling. It can't stop you from sending that information to the wrong person.

Episode 05 — The Takeaway
  • The padlock was never supposed to be a “this website is safe” badge. It only signifies encrypted transit.
  • HTTPS protects the connection between your browser and the server. That's essential, and we absolutely want it. But trust is a completely different question.
  • Don't stop at “Is this connection secure?” Also ask: “Am I on the website I actually intended to visit?”
  • Remove the attacker's link from the equation. Navigate to known accounts directly or open official apps rather than tapping urgent message links.

Sources & Further Reading

The technical standards, browser telemetry, and CA governance details cited in this episode are grounded in documentation from the Chromium project, Let's Encrypt, MDN Web Docs, and the Internet Engineering Task Force (IETF):

🔒
Chromium Blog — An Update on the Lock Icon
Google's Chrome security team explains why Chrome replaced the padlock with a tune icon, citing that only 11% of users understood it and nearly all phishing sites deploy HTTPS.
Read Chromium Security Update ↗
📜
Let's Encrypt — The CA's Role in Fighting Phishing and Malware
Policy paper clarifying that Domain Validation (DV) certificates establish encrypted wire transport to a domain, without verifying merchant safety or site reputation.
Read Let's Encrypt Position Paper ↗
🛡️
MDN Web Docs — Transport Layer Security (TLS)
Authoritative reference detailing the core cryptographic properties of TLS: data confidentiality, message integrity, and server authentication.
MDN TLS Documentation ↗
📐
IETF RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3
The official Internet standard specifying zero-RTT handshakes, forward secrecy, and deprecated insecure cipher suites across modern web infrastructure.
Read RFC 8446 Standard ↗
🏛️
CA/Browser Forum — Baseline Requirements for Publicly-Trusted Certificates
Global industry regulations defining technical verification criteria for Domain Validation (DV), Organization Validation (OV), and certificate trust anchors.
CA/Browser Forum Baseline Rules ↗
📊
Anti-Phishing Working Group (APWG) — Phishing Activity Trends Report
Longitudinal intelligence showing that over 85% of active phishing websites operate using valid TLS certificates to exploit consumer trust in the padlock.
APWG Threat Trends ↗
⚠️
CISA / US-CERT Alert — HTTPS Phishing Websites
Federal security alert warning organizations and consumers that HTTPS only indicates encrypted transport, not website legitimacy or safety.
CISA HTTPS Phishing Alert ↗
🌐
Electronic Frontier Foundation (EFF) — The Path to 100% HTTPS
Historical analysis of the Encrypt the Web campaign and why universal transit encryption decoupled cryptographic security from organizational trustworthiness.
EFF Encrypt the Web ↗
🔎
Netcraft — Web Server & Phishing Certificate Survey
Empirical Internet-scale telemetry tracking criminal certificate acquisition trends and automated certificate issuance abuse.
Netcraft Internet Research ↗
📑
NIST Special Publication 800-52 Rev. 2 — Guidelines for TLS Selection & Use
Federal standard establishing cryptographic boundaries, server identity verification rules, and transit security requirements.
NIST TLS Implementation Guide ↗
Next Episode in Series · Episode 06

Are Passkeys Finally Going to Kill Passwords?

Passkeys replace shared passwords with asymmetric public-key cryptography. How they make credential phishing virtually impossible, why they don't stop session theft, and whether passwords will ever truly disappear.

Read Episode 06 →