Everyone knows the padlock in the browser address bar means the site is "secure". But secure in what sense? Most people assume it means the site is trustworthy. It doesn't. It means the connection is encrypted. Those are very different things.
A phishing site can have a padlock. A site stealing your credit card details can have a padlock. The padlock tells you nobody is intercepting the traffic between your browser and the server - it says nothing about what the server itself does with your data.
So what does HTTPS actually do?
It wraps HTTP traffic in TLS (Transport Layer Security), encrypting everything in both directions. Your request, the response, the cookies, the headers - all of it. Without HTTPS, anyone on the same network can read it in plain text.
Three things HTTPS gives you:
- Encryption - nobody in the middle can read the traffic
- Integrity - nobody in the middle can tamper with it without detection
- Authentication - the certificate verifies you're talking to the actual server, not an impersonator
The handshake
Before any HTTP data flows, the browser and server do a TLS handshake. In TLS 1.3 (the current version) this takes one round trip:
- Browser sends supported cipher suites and a random value
- Server sends its certificate and picks a cipher suite
- Browser verifies the certificate against a trusted Certificate Authority
- Both sides derive a shared session key using Diffie-Hellman - without ever sending the key itself across the network
- Encrypted traffic begins
The clever bit is step 4. Asymmetric encryption (slow, uses public/private key pairs) is only used to establish the shared secret. After that, symmetric encryption (fast, single shared key) handles the actual data. You get the security of asymmetric with the speed of symmetric.
What certificates actually prove
A TLS certificate contains the server's public key and a signature from a Certificate Authority (CA) - an organisation your browser already trusts. The CA has verified the domain owner controls the domain before signing.
When your browser sees the certificate, it checks the CA signature. Valid signature from a trusted CA = the certificate is legitimate. This is why self-signed certificates get a browser warning - there's no trusted third party vouching for them.
SSL is dead, TLS is what you're using
When people say "SSL certificate" they mean TLS certificate. SSL 2.0 and 3.0 are deprecated and broken. TLS 1.0 and 1.1 are disabled in modern browsers. TLS 1.2 is still around but being phased out. TLS 1.3 is what you want - it dropped several legacy features that had caused vulnerabilities in older versions.
What HTTPS doesn't protect
- The domain name - the hostname you're connecting to is visible in DNS lookups and in the SNI field of the TLS handshake, even over HTTPS
- The server itself - once data arrives at the server, HTTPS is done. If the server stores passwords in plain text, HTTPS didn't help
- Your device - malware that intercepts traffic before it's encrypted bypasses HTTPS entirely
The padlock is meaningful. It's just not the whole story.
For a more detailed breakdown of the handshake steps and the SSL/TLS version history, datatoolkit.net/learn/how-does-https-work covers it. SHA-256 - the hash algorithm used in TLS certificate signatures - can be tested at datatoolkit.net/sha256.