The padlock in your browser does not mean "this site is safe." It means something more precise: the connection is encrypted, and the server proved its identity before any data moved. That guarantee comes from TLS, the protocol sitting underneath the S in HTTPS.
HTTPS is just HTTP over TLS
HTTP — the protocol for requests and responses, GET and POST, headers and bodies — has no built-in security. Anyone on the network path can read or tamper with it. HTTPS does not replace HTTP; it wraps it. The application still speaks ordinary HTTP, but the bytes travel through a TLS (Transport Layer Security) tunnel that handles encryption and authentication.
TLS is the modern successor to SSL, which is why people still say "SSL certificate" out of habit even though the protocol in use is TLS. The job splits into two phases: a handshake that sets everything up, then bulk data transfer over the secured channel.
The handshake: agreeing on keys without ever sending them
When you connect to https://example.com, the client and server run a handshake before a single HTTP byte is sent. Conceptually it does three things: agree on a cipher suite (which algorithms to use), verify the server's identity, and establish a shared secret key.
The clever part is the key exchange. The server has a key pair — a public key it hands out freely, and a private key it never reveals. Asymmetric cryptography means anything encrypted toward the public key can only be undone with the private key. The handshake uses this asymmetric math to bootstrap a shared symmetric key that both sides end up holding, without that key ever crossing the wire in the clear.
Why bootstrap a second key at all? Because asymmetric crypto is slow. It is great for setting up trust but too expensive to encrypt every byte of a large download. Symmetric encryption — where both sides use the same key — is far faster. So TLS uses the expensive asymmetric step once, to safely agree on a cheap symmetric key, then encrypts the actual traffic with that symmetric key. Best of both: secure setup, fast throughput.
1. Client: "hello, here are ciphers I support"
2. Server: "hello, let's use this one — and here is my certificate"
3. Both: key exchange -> derive shared symmetric session key
4. Both: "finished" (encrypted) -> bulk HTTP now flows encrypted
Certificates and the chain of trust
Encryption alone is not enough. If you encrypted a session with an attacker who intercepted your connection, you would have a perfectly private conversation with the wrong party. That is where certificates come in.
A certificate binds a public key to an identity (a domain name) and is digitally signed by a Certificate Authority (CA) — an organization browsers and operating systems already trust. Your machine ships with a trust store: a built-in list of root CA certificates. When the server presents its certificate, the client checks the signature, then follows the chain — the server's certificate is usually signed by an intermediate CA, which is signed by a root CA in the trust store. If the chain leads to a trusted root and the domain matches, the identity checks out. If anything is broken or expired, you get the dreaded full-page warning.
The certificate is what stops a man-in-the-middle. If TLS only encrypted traffic but skipped identity verification, an attacker could sit between you and the server, present their own key, and decrypt everything — you would never know. The signed certificate proves the public key actually belongs to the domain you typed, so the attacker cannot impersonate the real server without a CA-signed certificate for it.
What HTTPS protects — and what it does not
HTTPS gives you three things: confidentiality (eavesdroppers see ciphertext, not your data), integrity (tampering is detected, so the response cannot be silently altered in transit), and authentication of the server (you are talking to who the certificate says you are).
What it does not give you is total privacy about where you are going. The destination IP address is visible to anyone watching the network, and DNS lookups have historically been unencrypted, revealing the hostname you are resolving. TLS also includes the requested hostname in a handshake field called SNI (Server Name Indication), historically sent in cleartext so that servers hosting many sites on one IP know which certificate to present. So observers could often tell which site you visited even when the page contents stayed encrypted. Encrypted DNS and encrypted-SNI efforts aim to close that gap, but the classic model leaks the destination even while protecting the payload.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)