HTTPS and the padlock: what it protects and what it doesn't

For years people were told: “Look for the padlock before you type anything in.” That advice did a lot of good. It also left many people believing the padlock means this site is safe. It doesn’t. It means something narrower and still very important.

Yesterday we saw that your session cookie is the key to your account. Today is about the tunnel that keeps that key, and everything else, from being read or changed on its way across the internet.

The three jobs HTTPS does

HTTPS is ordinary HTTP sent through an encrypted connection made with TLS (Transport Layer Security). That connection does three things at once:

Privacy. Nobody between you and the server can read what’s being sent: not the café Wi-Fi, not your internet provider, not anyone else along the route.
Integrity. Nobody along the way can change the data without it being detected. No injected ads, no swapped download links, no altered bank details.
Identity. You’re really talking to the server for the name in the address bar, not someone pretending to be it.

All three matter. Privacy without identity is useless: an encrypted conversation with an impostor is still a conversation with an impostor.

How the server proves who it is

On Day 1 we mentioned the TLS handshake. Here’s the identity part in a little more detail.

The server shows your browser a certificate. Think of it as an ID card with three key facts: which domain names it covers, when it expires, and which certificate authority (CA) issued it. Your browser and operating system ship with a list of CAs they trust.

Before a CA issues a certificate, the site owner has to prove they control the domain, usually by placing a file on the site or a record in its DNS. So when your browser accepts a certificate for cybersearch.in, it’s trusting that a recognised authority checked that whoever is answering really controls cybersearch.in.

If the name doesn’t match, the date has passed, or the issuer isn’t trusted, the browser stops you with a full-page warning.

Why it matters for security

Without HTTPS, everything we’ve covered so far falls apart:

Your password crosses the network in readable form when you log in.
Your session cookie can be copied by anyone on the same network, which is the same as copying your login.
The page itself can be modified on the way, for example to add a fake login form or a malicious script.

With HTTPS and the right cookie settings from Day 3, those risks drop sharply. That’s why browsers now label plain HTTP pages “Not secure”, and why free certificates from services like Let’s Encrypt made HTTPS the normal case almost everywhere.

What the padlock does NOT tell you

This is the part most people miss. The padlock says the connection is private and that you reached the domain in the address bar. It says nothing about:

Whether the domain is the one you meant. paypa1-secure-login.com can get a perfectly valid certificate. Phishing sites almost all use HTTPS now.
Whether the people running the site are honest. A certificate proves control of a domain, not good intentions.
Whether the site itself is secure. A site can have a flawless HTTPS setup and still store passwords badly or have a bug that leaks data.
Whether your own device is clean. Malware on your computer sees everything before it’s encrypted.

A better habit than “look for the padlock” is “read the domain name”. The padlock is the minimum, not the verdict.

The warning page is your friend

When a browser shows “Your connection is not private”, it’s because one of the identity checks failed. Sometimes it’s harmless, like a site owner forgetting to renew a certificate. But from where you sit, a harmless mistake and someone actively intercepting your connection look exactly the same.

So the safe rule is simple: on any site where you log in, pay or share anything personal, don’t click through a certificate warning. Come back later, or reach the site another way.

What site owners need beyond “having a certificate”

Getting a certificate is the easy part. A solid HTTPS setup also includes:

Redirect every HTTP request to HTTPS with a 301, as we saw on Day 2.
Send the HSTS header (Strict-Transport-Security) so browsers refuse to use plain HTTP for your site at all, even if someone types http:// or clicks an old link.
Automatic renewal. Modern certificates last months, not years. Expired certificates are one of the most common causes of outages, and automatic renewal removes the risk.
No mixed content. If an HTTPS page loads scripts or images over plain HTTP, those pieces can be tampered with. Browsers block most of it, but it should be fixed at the source.
Modern TLS versions only. TLS 1.2 and 1.3 are current. Older versions have known weaknesses and should be switched off. Most hosting providers handle this for you.

Check a site yourself

Click the padlock (or the “site information” icon) in the address bar and open the certificate details. Look at who it was issued to, who issued it, and when it expires.
For your own site, run a free test at SSL Labs. It grades your configuration and explains anything that needs fixing.
Check your HSTS header with securityheaders.com.

What you can do today

If you browse the web:

Read the domain name, not just the padlock, before you log in or pay. Bookmarks for your bank and email are safer than links in messages.
Never click through a certificate warning on a site where you log in or pay.
Keep your browser and operating system updated so their list of trusted authorities and their TLS support stay current.

If you run a website:

Make sure every page is served over HTTPS and plain HTTP redirects to it.
Turn on automatic certificate renewal and set a reminder to check it works.
Add an HSTS header once you’re confident every part of the site works over HTTPS.
Run an SSL Labs test and fix anything below an A grade. MDN’s guide to HSTS explains the header in detail.

Coming up next

On Day 5 we’ll go back to the very first step of every page load, DNS: how your browser turns a name into an address, and the ways that lookup can be abused.