Almost every site you visit now loads over HTTPS, and your browser shows a padlock to prove it. That padlock is the most widely seen security indicator on the internet — and one of the most widely misunderstood.
SSL and TLS are the protocols doing the work behind it. This guide explains what they genuinely protect, what the padlock does not tell you, and what your connection still reveals even when everything is encrypted correctly.
Key Takeaway:
TLS proves you are talking to the server that controls that domain name, and stops anyone in between reading the conversation. It says nothing whatsoever about whether that server is run by honest people.
What TLS Actually Does
| Job | What it means in practice |
|---|---|
| Authentication | Confirms the server holds a valid certificate for the domain in your address bar |
| Encryption | Scrambles the data so anyone intercepting it sees unreadable noise |
| Integrity | Detects any tampering in transit — altered data is rejected, not silently accepted |
The third one is quietly important. Without integrity checking, an attacker on the same network could modify pages as they travel to you — injecting scripts or swapping payment details — even without being able to read them.
SSL vs TLS: The Naming Confusion
SSL (Secure Sockets Layer) was the original protocol. It was replaced by TLS (Transport Layer Security) in 1999, and every version of SSL has been formally deprecated since 2015 — SSL 3.0 fell to the POODLE attack and has been unsafe for a decade.
The industry simply never updated its vocabulary. When a hosting company sells you an “SSL certificate”, you receive a TLS certificate. The terms are used interchangeably in marketing, but only TLS is actually running.
| Version | Status in 2026 |
|---|---|
| SSL 2.0 / 3.0 | Dead. Broken and disabled everywhere |
| TLS 1.0 / 1.1 | Deprecated in 2020–21; removed from modern browsers |
| TLS 1.2 | Still secure and very widely used |
| TLS 1.3 | Current standard — faster, and legacy weak ciphers removed |
The Handshake, Explained Simply
Before any page data moves, your browser and the server negotiate. Stripped of the mathematics, it goes like this:
- Hello. Your browser says which TLS versions and cipher suites it supports.
- Certificate. The server replies with its certificate and picks a cipher you both understand.
- Verification. Your browser checks that certificate: is it issued by a Certificate Authority the system trusts, is it still valid, and does it actually cover this domain?
- Key exchange. Both sides derive a shared secret without ever transmitting it, so anyone recording the exchange cannot reconstruct it.
- Encrypted session. Everything after this point is scrambled with that shared key.
TLS 1.3 compressed this from two round trips to one, which is why modern HTTPS sites often feel faster to connect than older ones. Modern key exchange also provides forward secrecy: each session uses fresh keys, so an attacker who later steals the server’s private key still cannot decrypt traffic they recorded in the past.
Certificates and Who Issues Them
A certificate is a signed statement from a Certificate Authority saying “the holder of this certificate controls this domain”. Your operating system and browser ship with a list of CAs they trust, and that trust chain is what your browser is verifying during the handshake.
The overwhelming majority of certificates today are Domain Validated. To obtain one, you prove you control the domain — typically by responding to an automated challenge. That is the entire check. It takes about a minute, it is free through providers like Let’s Encrypt, and no human ever looks at who you are or what you intend to do.
⚠️ The Padlock Does Not Mean the Site Is Safe
This is the single most consequential misunderstanding about HTTPS, and it follows directly from how Domain Validated certificates work. Anyone who registers a domain can get a valid certificate for it within minutes, at no cost — including someone who registered it this morning to impersonate your bank.
A phishing site with a padlock is not a broken padlock. The padlock is working exactly as designed: your connection to the criminal’s server is genuinely, properly encrypted.
| The padlock proves | The padlock does not prove |
|---|---|
| Your connection is encrypted | The site is legitimate or reputable |
| Nobody in between can read it | Your data is safe once it arrives |
| The server controls this exact domain | The domain belongs to the brand it resembles |
| The page was not altered in transit | The page is honest about what it does |
The practical habit is simple: read the domain, not the padlock. paypal-secure-login.com can carry a flawless certificate, because whoever registered it does control that name. It is simply not PayPal. Our scam spotting test works through exactly this kind of judgement call.
What TLS Hides From Your ISP — and What It Doesn’t
Encryption protects the contents of your traffic. A surprising amount of context remains visible to your ISP, your network administrator, or anyone monitoring the connection:
- Hidden: the pages you view, what you type, form data, passwords, cookies.
- Visible: which domain you connected to, the server’s IP address, when you connected, how long you stayed, and roughly how much data moved.
The domain leaks through two channels. Your DNS lookup happens before the handshake and is usually unencrypted, and the handshake itself carries the hostname in a field called SNI so the server knows which site you want. So HTTPS hides what you read on a site, not that you visited it.
Closing the DNS half of that gap is what DNS over HTTPS is for, and it is worth understanding how much your ISP’s DNS server already logs. For a look at what interception on a shared network actually involves, see what network sniffing is.
🔒 On public Wi-Fi
TLS does most of the heavy lifting on an untrusted network — the coffee-shop attacker cannot read your encrypted sessions. What they can still build is a list of every domain you visited and when. A VPN moves that visibility from the local network to your VPN provider instead, which is a meaningful improvement when the local network is a stranger’s: IPVanish is one option. Check yours is not leaking lookups with our free DNS leak test.
Common TLS Errors and What They Mean
| Error | Usual cause |
|---|---|
ERR_CERT_DATE_INVALID | Certificate expired — or your device’s clock is wrong |
ERR_CERT_AUTHORITY_INVALID | Self-signed, or issued by a CA your device doesn’t trust |
ERR_CERT_COMMON_NAME_INVALID | The certificate doesn’t cover the domain you asked for |
ERR_SSL_PROTOCOL_ERROR | No shared TLS version or cipher — often outdated software |
Clicking through a certificate warning is safe only when you understand precisely why it appeared. On a network you do not control, a certificate warning is one of the few signals that someone may genuinely be intercepting your traffic — treat it seriously rather than as an obstacle.
Frequently Asked Questions
Is a site with a padlock always safe?
No. The padlock confirms encryption and domain control, nothing more. Phishing sites routinely carry valid certificates because basic ones are free and automatic. Always check the domain name itself.
What’s the difference between SSL and TLS?
SSL is the obsolete predecessor; TLS replaced it and is what actually runs today. “SSL certificate” is a marketing term that has outlived the protocol it names.
Can my ISP see what I do on HTTPS sites?
Not the content. They can see which domains you connect to, when, and how much data moves — via your DNS lookups and the hostname in the TLS handshake.
Does HTTPS protect me from viruses?
No. It secures data in transit. A malicious file downloaded over HTTPS arrives perfectly encrypted and just as malicious.
Are free certificates less secure than paid ones?
No. The encryption is identical. Paid certificates may include organisation validation and warranties, but they do not make the connection stronger.
Should I ever click through a certificate warning?
Only if you know exactly why it appeared — a device with the wrong date, or a server you administer yourself. On public Wi-Fi, treat it as a possible interception attempt and stop.
Do I still need a VPN if everything uses HTTPS?
It depends what you are protecting. HTTPS already hides content. A VPN hides which domains you visit from the local network and your ISP, moving that trust to the VPN provider instead.