Daniel Garcia
The site uses HTTPS. Can I trust it?
Versão portuguesa →A protected connection can take us safely to the wrong destination. HTTPS matters, but we need to understand where its protection ends.
In this article
‘It uses HTTPS. It must be safe.’
We receive a message about a parcel. There is a small fee to pay before the delivery can go ahead. We open the link, find a familiar logo and see that the address starts with https://.
The browser even says the connection is secure. So we can enter our card details, right?
This is exactly where we should stop.
There is a good reason for the advice to look for HTTPS. The problem arises when we turn it into a guarantee about everything on the site. A secure connection and a trustworthy website are not the same thing.
I like to think of HTTPS as a sealed envelope. It makes it harder for someone to read or alter the message along the way. But it does not choose the recipient for us. If we send the envelope to a scammer, they still receive it. It simply arrives securely sealed.
What does HTTPS actually protect?
HTTPS lets the browser and the website exchange information over a connection protected by a protocol called TLS. We do not need to memorise the acronym; what matters is understanding its three main functions:
- Encryption: makes it harder for third parties along the route to read the contents of the communication, such as passwords or form data.
- Integrity: protects the communication against changes made along the way going undetected.
- Authentication of the destination: the browser checks the certificate presented for the address it is connecting to, according to its trust rules.
When these checks work, the data is protected in transit to the specified destination. Mozilla explains these connection security indicators.
That is the crucial detail: to the specified destination. If the address belongs to a fake site, a valid HTTPS connection can deliver our data to it securely. The problem is no longer someone intercepting it along the way. It is who receives it.
The certificate did not put the shop through its paces
A certificate used for an HTTPS connection is not a certificate of good conduct.
For domain validation certificates, a common type, issuance checks control of the domain. That is not the same as investigating a shop’s honesty, testing all its software or confirming that it will deliver the order.
Let’s Encrypt itself explains that it issues domain validation certificates and provides guidance on reporting sites that use them for phishing or malware. The fact that these situations exist helps dispel the idea that HTTPS and fraud are incompatible.
A site using HTTPS can therefore ask for our password on a fake page, offer a malicious file or take money for a product it never sends. A legitimate site can also have vulnerabilities or be compromised. Protecting the connection does not audit the application at the other end.
Nor does our data become invisible to whoever runs the site. If we enter it into a form, that service receives it for processing. HTTPS protects the journey; it does not determine what the recipient does afterwards.
Back to the parcel
Imagine this scenario: the message says the delivery will be held up unless we pay a fee within the next few hours. We are expecting a purchase and the amount seems insignificant.
The page has the courier’s logo, a photograph of a van and a neatly presented form. There are no obvious language mistakes. HTTPS works.
What do we still need to check?
Whether we are really on the courier’s website and whether the request relates to a genuine situation.
The logo does not answer that: it can be copied. Neither does a professional appearance. And the certificate may be perfectly valid for the domain used in the scam.
In this scenario, I would close the page and open the courier’s app or an official address I already knew. I would check the delivery there, without returning to the link in the message. If I needed to contact support, I would find the contact details through that channel, not on the suspicious form.
The small amount does not make the request harmless either. The form may be interested in more than those few cents: card details, a password or an authorisation code could be the real prize.
Urgency serves another purpose: leaving us less time to ask these questions. The parcel seems to be in a hurry. So does whoever sent the message.
The address deserves more attention than the logo
Compare these two fictional addresses:
https://transportadora.example/entrega
https://transportadora.example.confirmacao.example/entregaBoth contain the word ‘transportadora’, Portuguese for a delivery company. Both use HTTPS. But in the second, the domain is confirmacao.example; the transportadora.example part has been placed before it as a subdomain. That does not make it the first address.
The .example ending is reserved for examples; these addresses do not represent real couriers.
We do not need to turn every visit into a lesson on domain names. It is worth expanding the full address, though, and comparing it with the official address we know. The right word somewhere in the URL is not enough. A similar name, a changed letter or words such as ‘secure’ and ‘verified’ do not prove who is at the other end either.
On a mobile phone, where part of the address may be hidden, this is particularly useful. If we are still unsure, it is better to use a channel we already know than to guess whether that long name deserves our trust.
A pause before sharing data
I would ask three questions before entering a password, personal information or payment details:
- How did I get here? Did I open the site through a known address, or arrive from an unexpected message, an advert or a QR code? The route does not settle everything, but it helps us understand what still needs checking.
- Does the request make sense? Was I expecting this action? Why am I being asked for this information or this code now? A threat of an immediate account block deserves confirmation through another channel.
- Can I check outside this page? The official app, a previously saved bookmark or independently obtained contact details are better starting points than information supplied by the suspicious message itself.
Portugal’s ARTE recommends checking the source, accessing official services directly and being wary of urgency. These are useful habits even when the site presents an HTTPS connection without warnings.
If the browser displays a certificate warning or flags a dangerous page, we should stop rather than bypass it to get the task done. There may be a configuration mistake or a threat; the warning alone does not distinguish between the two. We need to check before continuing.
The reasoning works both ways: a warning deserves attention; the absence of a warning does not guarantee trustworthiness. Browser protections help, but they do not necessarily recognise every scam.
So is HTTPS useless?
It is useful, and we very much need it. It provides essential protection for communication on the Web. The conclusion is not to replace HTTPS with HTTP or ignore the browser’s indicators.
It is to interpret them correctly. The symbol can vary between browsers and versions; we should look for information about the connection rather than treat a padlock as a seal of approval for the whole site.
For me, the useful question goes beyond ‘does it use HTTPS?’ to: ‘the connection is protected, but am I talking to the intended recipient, and does this request make sense?’
The envelope should be sealed. Checking who we hand it to is still our responsibility.
