HTTPS and TLS Handshakes

HTTPS is ordinary HTTP carried inside an encrypted connection. The reason it feels mysterious is that two strangers on the internet need to agree on secret keys before they can talk privately. The TLS handshake is the process that makes that agreement possible.

What the handshake is trying to achieve

The client wants proof that it reached the right server, not an impostor. The server wants to present an identity the client can verify. Both sides then want to create shared session keys that will protect the rest of the conversation. Public-key cryptography helps with identity and key agreement. Symmetric encryption handles the bulk data afterwards because it is much faster.

The simple flow

When a browser connects to https://example.com, it starts a TLS handshake. The server responds with its certificate, which includes its public key and the hostname it is valid for. The browser checks whether that certificate chains back to a trusted certificate authority in its trust store, whether the name matches, and whether the certificate is still valid.

If those checks pass, the browser and server perform a key agreement step. In modern TLS this is usually ephemeral Diffie-Hellman, which lets them derive the same shared secret without sending that secret across the network directly. From that shared secret they derive session keys.

At that point the handshake is mostly done. Both sides now use symmetric encryption and message authentication to protect the actual HTTP requests and responses. Anyone watching the traffic can still see some metadata, such as the destination IP address and roughly how much data moved, but not the page contents or credentials.

Why this is better than locking everything with a public key

Public-key operations are slower and solve a different problem. They help establish trust and exchange material safely. Symmetric encryption is then used for the ongoing traffic because it is efficient enough for every request body, response body, and header.

Modern TLS also aims for forward secrecy. That means if the server's long-term private key leaks later, old captured sessions should still remain protected because each session used fresh ephemeral keys.

What HTTPS does and does not guarantee

HTTPS protects against network eavesdropping and many forms of tampering between client and server. It does not guarantee that the site itself is honest, that the endpoint device is not infected, or that the user cannot be tricked by phishing on a lookalike domain.

So the short version is this: the handshake proves identity, creates short-lived shared secrets, and hands the real data exchange to fast symmetric encryption. That is how the web turns an open network into a channel private enough for passwords, banking, and everyday browsing.