How HTTPS Actually Works: TLS Handshakes and Certificates

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.

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.