You have been told to look for the padlock before entering your credit card number. You have seen it in the address bar thousands of times. Most people treat it as a safety certificate: padlock present, site safe, proceed. But that reading is incomplete, and the gap between what the padlock actually measures and what people think it measures is exactly the gap phishing attackers exploit.
The padlock is real, and it matters. But it is measuring something more specific than "this website is trustworthy." Understanding what it actually checks makes you a meaningfully better judge of what to trust online.
What the Internet Looked Like Before HTTPS
The earliest version of the web ran on HTTP, which stands for Hypertext Transfer Protocol. HTTP sends everything as plain text: every page you request, every form you fill in, every password you type. The data travels across networks, through routers, over shared wifi, and arrives at the server. Nothing is hidden along the way.
This creates a simple attack: anyone who can observe the network traffic between you and the server can read your data. At a coffee shop, a hotel, or an airport, that means anyone running packet-capture software on the same wifi connection. It also means anyone who operates infrastructure in the path of your traffic, such as an internet service provider, can see everything in plain text.
This is called a man-in-the-middle attack in its passive form: an eavesdropper observes without interfering. In its active form, the attacker modifies the traffic in both directions, changing what the server sends you or what you send the server, with neither side knowing.
HTTPS (the S standing for Secure) was designed to close exactly this gap.
What the Encryption Layer Actually Does
HTTPS adds a protocol called TLS (Transport Layer Security, replacing an older version called SSL) between your browser and the web server. TLS creates an encrypted channel so that even if someone intercepts the traffic, they see only unreadable scramble.
Here is the analogy that makes this mechanism click.
Imagine you and someone across town need to exchange confidential letters, but every postal worker who handles the envelope can open and read it. A locked box solves the problem, but you both need the same key, and you cannot safely mail that key because the postal workers would read it too.
TLS solves this with a mathematical trick called a key exchange. You and the server each generate part of a puzzle. You share those parts publicly, over the open network, in a way that lets both sides calculate the same final secret without ever transmitting the secret itself. Anyone who intercepts only the public pieces cannot reconstruct it. Once both sides have the shared secret, every byte of the conversation is encrypted with it.
This handshake takes a few milliseconds and is invisible to you. The padlock in your browser is the signal that it completed successfully and that the connection is now encrypted.
- Data travels as plain text
- Anyone on the same network can read it
- An attacker can modify what you send or receive without you knowing
- Data is encrypted before it leaves your device
- Intercepted traffic is unreadable scramble
- A certificate confirms you are connected to the legitimate domain owner
What a Certificate Is and Why It Matters
Encryption solves the eavesdropping problem. But it does not solve impersonation on its own.
An attacker could set up a server with a perfectly valid encrypted connection. Your browser would negotiate the key exchange, your traffic would be encrypted, and none of it would ever reach the real website. The encryption would be real. The destination would be wrong.
The certificate layer is what prevents this. Every HTTPS website holds a digital certificate issued by a certificate authority (CA): an organization that browsers and operating systems have agreed to trust. Comodo, DigiCert, and Let's Encrypt are three well-known ones. When a website operator wants a certificate, they prove to the CA that they actually control the domain name. The CA then cryptographically signs the certificate, essentially vouching for it.
When your browser connects to an HTTPS site, it runs three checks on that certificate almost instantly:
- Is this certificate signed by a CA my browser trusts?
- Does the domain name in the certificate match the site I am visiting?
- Has the certificate expired or been revoked?
All three must pass. If any fails, you get a browser warning instead of the padlock. The padlock means all three passed.
The Part That Surprises Most People
Here is where the padlock's meaning gets narrower than most people expect.
The certificate authority proves you are talking to whoever legitimately controls this domain name. It does not vouch for whether that organization is who they claim to be, or whether they deserve your trust.
Phishing websites can have valid HTTPS certificates and a green padlock. An attacker registers a domain such as paypa1.com or yourbank-secure.com, proves to a certificate authority that they own that domain (which is a purely technical check, not a business background check), and receives a signed certificate for it. They build a convincing replica of the real site. Every connection is encrypted. The padlock appears. Your login credentials go directly to an attacker.
This is not a failure of TLS. TLS is doing exactly what it promises: encrypting the traffic between your browser and the server at the other end. The problem is that the padlock has been presented as a trust signal, when it is really an encryption signal. Those are different things.
Think of it this way. HTTPS is a sealed envelope. Anyone who intercepts it in transit sees nothing. But a sealed envelope with "your bank" written on the outside is not proof that your bank sent it. It is proof the contents are private between you and whoever actually sealed it. If the return address was faked, the seal does not help you.
What to Check Instead
If the padlock is not enough on its own, what should you actually look at?
Read the domain name carefully, from right to left. The authoritative part of a web address is the two segments immediately before the first forward slash: the top-level domain (the .com or .co.uk) and the name directly to its left. In paypal.evil.com/login, the domain is evil.com, not paypal.com. In secure.paypal.com, the domain really is paypal.com and the subdomain is legitimately theirs. The trick in phishing URLs is usually in that second segment. Read it before you click anything.
Never click email links to financial or account-management sites. Phishing campaigns exist specifically to route you through a convincing lookalike via a link you did not choose. Bookmark the sites you rely on for anything sensitive and navigate there directly. The extra effort takes seconds. The exposure from clicking a convincing phishing link does not resolve in seconds.
Use the padlock as a floor, not a ceiling. Never submit sensitive data on a site without the padlock: an unencrypted HTTP connection exposes your data on the wire to anyone watching. But the padlock is a minimum condition, not a clean bill of health. The rest of the judgment is yours.
Encryption and identity are both part of a secure connection. HTTPS delivers both: your traffic is private, and the domain name has been verified by a trusted third party. What it cannot do is verify whether the identity confirmed is one you should trust. That final check remains yours, and it takes about three seconds: read the domain name, confirm it is what you expected, then proceed.
If any of this connects to something your team is working through on the IT or security side, drop me a message. Happy to talk through it.
Comments