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.
So you continue.
And that's exactly where one of the biggest misunderstandings about web security begins.
For years, we've been told:
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:
Those are two very different things.
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.
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:
That's not HTTPS's job. And that's the part people often miss.
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.
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.
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:
“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:
you're actually on something like:
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.
Yes. And this is where another misunderstanding starts.
People sometimes imagine that getting a certificate means somebody has inspected the website and decided:
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.
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:
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:
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.
That's why these attacks often work. Think about when you usually receive these messages:
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?”
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.
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.
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.
So these things can all be true at the exact same time:
That's why “My browser didn't warn me” shouldn't automatically become “It must be safe.”
For the person who clicked the link, the story might simply be:
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.
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.”
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.
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:
Click a scenario to see how deceptive websites exploit the HTTPS padlock:
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.
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:
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.
For years, we said: “Look for the padlock.”
Maybe the better advice today is: “Check the destination.”
Because this combination is completely possible:
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:
Because encryption can protect your information while it's travelling. It can't stop you from sending that information to the wrong person.
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):
Have a question or a suggestion? Prepare an email below. Feedback is private and is sent only when you press Send in your email app.
Likes and claps are your personal reactions on this device.
You can also email Poorna directly.
Your feedback stays private. Nothing is sent from this page automatically.