What Does SSL Actually Protect?
HTTPS and SSL/TLS are synonymous with web security — but most people don't know what they actually protect against, or more importantly, what they don't protect against.
The padlock myth
The padlock icon in your browser's address bar has become synonymous with "this website is safe." This is a dangerous oversimplification. The padlock means exactly one thing: your connection to this server is encrypted. It says nothing about whether the server itself is trustworthy, whether the website is legitimate, or whether your data is secure once it arrives at the server.
Phishing sites — fake login pages designed to steal your credentials — routinely have valid SSL certificates and display the padlock. In 2019, the Anti-Phishing Working Group found that more than 50% of phishing sites used HTTPS. The padlock tells you the connection is private, not that the destination is honest.
What SSL/TLS actually does
SSL (Secure Sockets Layer) has been superseded by TLS (Transport Layer Security), though the terms are often used interchangeably. When you connect to an HTTPS website, TLS provides three security guarantees:
1. Encryption in transit
TLS encrypts all data transmitted between your browser and the server. Anyone intercepting the traffic — a coffee shop Wi-Fi operator, an ISP, a government network tap — sees only encrypted ciphertext, not the content of your communications.
This is what protects your passwords, credit card numbers, and messages when you submit a form on an HTTPS site. Without TLS, this data would travel as plaintext, readable by any intermediary.
Modern TLS (1.3, released 2018) uses ephemeral key exchange, meaning even if a server's long-term private key is later compromised, past sessions cannot be decrypted. This property is called forward secrecy.
2. Server authentication
Before encrypting anything, TLS verifies that you're actually connecting to the server you think you are — not an impersonator. It does this through the certificate chain:
- The server presents a digital certificate issued by a trusted Certificate Authority (CA).
- Your browser maintains a list of trusted root CAs (built into the OS and browser).
- The browser verifies the server's certificate is signed by a trusted CA and matches the domain you're connecting to.
This prevents man-in-the-middle attacks where an attacker intercepts your connection and impersonates the server. Without certificate verification, encryption alone would be useless — you'd be encrypting data straight to the attacker.
3. Data integrity
TLS uses message authentication codes (MACs) to ensure data hasn't been modified in transit. Any tampering — even a single bit flip — is detected and the connection is terminated. This protects against injection attacks where an intermediary tries to insert malicious content into a legitimate HTTP response.
Before HTTPS was ubiquitous, some ISPs injected ads into HTTP responses. TLS's integrity protection makes this impossible over HTTPS — the browser would detect and reject any modification.
What SSL/TLS does not protect
Understanding TLS's limitations is just as important as understanding what it does:
- It doesn't verify the website is legitimate. A phishing site can have a valid certificate. TLS authenticates the server's identity (the domain), not the organization's trustworthiness.
- It doesn't protect data at rest. Once your data reaches the server, TLS is done. How the server stores, processes, and protects your data is entirely outside TLS's scope. Data breaches happen on servers — not in transit.
- It doesn't protect against malware on your device. If your computer or browser is compromised, an attacker can read data before it's encrypted or after it's decrypted — regardless of TLS.
- It doesn't hide which sites you visit. Your DNS queries (domain lookups) and the SNI (Server Name Indication) handshake reveal which domains you're connecting to, even over HTTPS. Your ISP can see you're visiting
example.com, just not what specific pages you view. - It doesn't prevent the server from being hacked. TLS protects the connection, not the destination. A server can be breached regardless of having valid SSL.
ℹ Quick rule of thumb
HTTPS protects your data on the wire. Once it leaves the wire, it's the server's responsibility — not TLS's.
Types of SSL certificates
There are three levels of validation for TLS certificates, ranging from instant automated issuance to weeks of manual verification:
| Type | Validation | Padlock displays | Use case |
|---|---|---|---|
| DV (Domain Validation) | Automated domain ownership only | Standard padlock | Blogs, personal sites, APIs |
| OV (Organization Validation) | Manual company identity verification | Standard padlock | Business websites |
| EV (Extended Validation) | Rigorous legal entity verification | Padlock (historically showed company name) | Banks, governments, e-commerce |
Let's Encrypt issues free DV certificates via an automated process, which is why virtually every website now has HTTPS. This democratized encryption — but it also means certificate presence alone is no longer a meaningful trust signal.
How to check a certificate
You can inspect any site's certificate directly in your browser by clicking the padlock icon and viewing certificate details. Look for:
- Validity dates — is the certificate currently valid and not expiring soon?
- Issued to — does the domain match what you're visiting?
- Issued by — is it a recognized CA like Let's Encrypt, DigiCert, or Sectigo?
- TLS version — modern sites should use TLS 1.2 or 1.3. TLS 1.0 and 1.1 are deprecated.
For a quick automated check, try our SSL Certificate Checker — it shows validity dates, issuer, expiry countdown, and all Subject Alternative Names (SANs) for any domain.