Skip to content
All tutorials

/tutorials/https-and-tls-explained

HTTPS and TLS, What the Padlock Is Actually Telling You

What encryption in transit protects against, what it does not, and why a valid certificate and a security header check both matter.

6 min read

Run SSL Checker

What encryption in transit actually protects

HTTPS protects the data moving between a visitor's browser and the server it is talking to. Anyone sitting on the same network, at a public wifi hotspot for instance, or any network the traffic passes through on its way, cannot read the contents or quietly alter them, because everything is encrypted for that specific connection. This is what the padlock icon is actually confirming.

It is worth being precise about what this does not cover. HTTPS says nothing about whether the website itself is trustworthy, whether the server storing your data afterward is secure, or whether the site is what it claims to be beyond the domain name matching the certificate. A convincing phishing site can have a perfectly valid certificate for its own lookalike domain.

SSL versus TLS, briefly

SSL was the original protocol, and every version of it is now considered insecure and long retired. TLS is its successor and what every modern site actually uses today. The name SSL stuck around in everyday conversation, and in terms like SSL certificate and SSL checker, simply out of habit, even though the protocol actually doing the work is TLS.

The handshake, in plain terms

Before any data is exchanged, the browser and server agree on an encryption method and exchange keys in a process called the handshake. The server presents its certificate during this exchange, the browser checks it against a trusted root, and once both sides agree everything checks out, an encrypted channel is established for the rest of the session. This entire process typically takes a fraction of a second and happens before a single byte of the actual page loads.

Why an expired certificate breaks things even though the encryption still works

The cryptography behind an expired certificate has not become weaker the moment the clock ticks past its expiry date. What has changed is that the browser can no longer confirm the identity claim is current, so it refuses to proceed and shows a warning rather than silently connecting anyway. This is a deliberate design choice: an expired certificate might mean nothing at all, or it might mean the domain has since been taken over by someone else entirely, and the browser has no way to tell the difference on its own.

Why HSTS matters alongside a valid certificate

A valid certificate means HTTPS works when a visitor uses it. The strict transport security header, checked by Frabs' Security Headers tool, tells the browser to always use HTTPS for this site going forward, even if someone types the address without it or follows an old link that still points at the insecure version. Without this header, a visitor can be quietly downgraded to an unencrypted connection for a single request, which is exactly the kind of gap an attacker on a shared network can use.

Checking your own site properly

Run the domain through the SSL Checker to confirm the certificate itself is valid, current and covers the right hostnames, then run it through Security Headers to confirm HSTS and the other headers browsers rely on are actually present. A valid certificate without HSTS still leaves a narrow but real gap that either check on its own would miss.