Why HTTPS does not mean a site is trustworthy

The encryption can be genuine while the website is fraudulent

A convincing phishing page can have a valid TLS certificate, load over HTTPS and trigger no certificate warning at all.

Nothing has gone wrong with HTTPS in that scenario.

The browser has protected the connection to the site you actually opened. The problem is that the site you opened belongs to the wrong person.

That distinction is easy to miss because the web spent years teaching people to associate HTTPS — and especially the padlock icon — with a vague idea of being “safe.” Chrome eventually changed its own interface partly because that interpretation was so persistent. In 2023, the Chromium team wrote that the lock icon did not indicate website trustworthiness and said its research found only 11% of participants understood the icon precisely. Chrome replaced the lock with a more neutral controls icon beginning with Chrome 117.

The technical protection remained. The trust badge disappeared.

That is the right mental model: HTTPS is evidence about the connection, not a character reference for whoever runs the website.

What HTTPS actually does

HTTPS is HTTP carried over Transport Layer Security, or TLS.

TLS gives a web connection three important properties: encryption, integrity and server authentication. MDN describes those as protection against reading traffic in transit, secretly modifying it in transit, and impersonating the server for the hostname being visited.

In ordinary browsing, that means an attacker sitting on the same café Wi-Fi should not be able to casually read the password you submit to an HTTPS site or rewrite the page while it travels between the server and your browser.

It also means the browser checks the site’s certificate. Among other things, the certificate must be valid for the hostname in the address bar and chain back to a certificate authority the browser trusts.

Those are meaningful protections. An HTTP checkout page asking for a card number is a serious warning sign.

But none of this answers the question most people care about when they ask whether a site is trustworthy:

Who is operating this site, and should I give them money or information?

TLS is not designed to answer that entire question.

A certificate can validate the wrong site perfectly

Imagine a real bank operates at:

bank.example

An attacker registers:

bank-security-check.example

If the attacker controls that second domain, there is nothing contradictory about obtaining a valid certificate for it. The certificate is supposed to establish that the server is authorized for bank-security-check.example. It is not supposed to decide whether the name is misleading, whether the page copies another company, or whether the operator plans to steal passwords.

Let’s Encrypt, one of the web’s major certificate authorities, documents how automated certificate issuance works. Its common HTTP-01 challenge asks an applicant to place a specific token at a specific location on the requested domain. If the validation system retrieves the correct response, domain control is established and a certificate can be issued.

That is useful because encryption should be widely available and easy to deploy. It also means a certificate is not a background check.

For the common domain-validated certificate, the key question is essentially: does this applicant control the domain they are requesting the certificate for?

A scammer can truthfully answer yes.

“Secure connection” and “trustworthy business” are different claims

The easiest way to avoid the confusion is to separate the claims.

Signal	What it can tell you	What it does not establish
HTTPS is active	Traffic to this site is protected in transit by TLS	The operator is honest
Certificate matches the domain	You reached a server authorized for that hostname	The hostname belongs to the company you intended to visit
No browser certificate warning	The certificate passed the browser’s connection checks	The products, claims or payment request are legitimate
Polished site design	Someone invested effort in presentation	The business exists, ships orders or honours refunds
Familiar brand logo	The page contains that brand’s visual assets	The brand controls the page

This is the same evidence problem that appears with screenshots and context. A piece of evidence can be completely genuine while supporting a much narrower conclusion than the viewer assumes.

The HTTPS connection may be real. The inference — “therefore this site is safe to trust” — is the unsupported part.

The website itself is one endpoint of the encrypted connection

There is another reason the phrase “your information is encrypted” can create false comfort.

Encryption protects data while it travels between you and the site. The site receives the data at the other end because that is the entire point of the connection.

If you type a password into a fake login page, HTTPS can protect that password from eavesdroppers while delivering it safely to the scammer’s server.

If you enter a credit-card number into a fraudulent checkout, TLS can prevent someone else on the network from intercepting it while the fraudulent operator receives exactly what you submitted.

The US Federal Trade Commission makes this distinction explicitly in its online-shopping guidance: HTTPS means the site is encrypted, but not necessarily legitimate. Its consumer guidance notes that scammers can encrypt sites too.

A private route to the wrong destination is still the wrong destination.

Browser makers stopped treating the lock like a trust mark

The padlock became a victim of its own success.

When HTTPS was unusual, highlighting an encrypted connection made sense. By 2023, Chromium said more than 95% of Chrome page loads on Windows were already using HTTPS. The exceptional state was no longer “secure site”; it was the remaining insecure HTTP connection.

The browser team also had a second problem: people were reading more into the lock than it meant. Chromium said nearly all phishing sites were already using HTTPS at the time of its 2023 post. The FBI had issued a similar warning years earlier, telling users not to trust a website simply because a lock icon or HTTPS appeared in the address bar.

Chrome’s answer was not to weaken HTTPS. It was to stop decorating normal transport security like an endorsement.

Other browsers may still use different icons or wording. The principle is the same: connection security and website reputation are separate layers.

HTTPS should still be required

The correction here is not “ignore HTTPS.”

A website asking for sensitive information without HTTPS is worse, not somehow more honest. The Canadian Centre for Cyber Security’s October 2026 shopping guidance recommends using sites with encrypted HTTPS connections and following browser security warnings.

It makes the other half of the rule equally clear: do not rely on the padlock or a website’s appearance alone to decide whether the site is legitimate.

HTTPS is therefore best treated as a minimum requirement.

No HTTPS on a public login, checkout or account page is a reason to stop.

HTTPS present means one important technical check passed. Keep checking.

Read the domain, not the decoration around it

For phishing, the most important part of the address bar is the actual domain you are visiting.

A fake site can put a trusted brand in its page title, logo, subdomain, URL path or marketing copy. None of those positions makes it the brand’s domain.

If a message tells you to sign in urgently, do not let the presence of HTTPS settle the question. Check the hostname carefully. Better still, navigate to the service through a bookmark, a known app or an address you already know rather than following the message’s link.

The FBI’s phishing guidance specifically recommends checking for misspellings and wrong domains. Canada’s Cyber Centre similarly recommends going directly to retailers’ official websites instead of clicking promotional links when there is doubt.

That advice is less visually satisfying than “look for the lock,” but it tests the part that actually changes in a lookalike-site attack.

Trust requires evidence outside the certificate

A certificate is one technical record. A business asking for money creates a much larger set of questions.

For an unfamiliar retailer, Canada’s Cyber Centre recommends looking for independent reviews, the length and consistency of the retailer’s online presence, complaints or scam reports, and functioning customer-service channels. The FTC similarly recommends researching unfamiliar sellers and using payment methods with meaningful dispute protections.

None of those checks is perfect on its own. Old domains can be compromised. Reviews can be manipulated. Real businesses can have complaints. New businesses can be legitimate.

The point is not to find a second magic badge.

It is to stop asking one narrow technical signal to answer every trust question at once.

A useful sequence is:

1. Connection: is HTTPS active, with no browser security warning?
2. Destination: is this the exact domain you intended to visit?
3. Context: did you arrive through an unexpected email, ad, text message or QR code pushing urgency?
4. Operator: can the claimed business or organization be corroborated independently?
5. Request: does the site want a password, payment method or personal information that makes sense for what you are doing?
6. Recovery: if the transaction goes wrong, are you using a payment or authentication method that limits the damage?

That last layer matters. Phishing-resistant sign-in methods such as passkeys are designed so a credential is tied to the service it was created for, reducing the usefulness of a lookalike login page. They do not make every site trustworthy, but they can make one common consequence of trusting the wrong site harder to exploit.

The padlock was never a review score

HTTPS solved a huge web-security problem: sending ordinary web traffic across untrusted networks without encryption or reliable server authentication.

It did not solve fraud.

A malicious operator deserves encryption too, in the narrow technical sense that the web is safer when traffic is not exposed to unrelated third parties. That does not transform the operator into someone worth trusting.

So the next time a site looks suspicious but the connection is HTTPS, do not ask whether the certificate is “real.” It probably is.

Ask the more useful question:

Is this the right domain, controlled by the people I think it is, asking me to do something I have independent reason to trust?

HTTPS can secure that conversation.

It cannot answer it for you.