When a site shows the padlock next to its address, what is really happening is that your browser and the server have just solved, in a fraction of a second, a problem of trust: proving who each one is and agreeing on a secret key without anyone being able to eavesdrop. That process is called the TLS handshake, and in its most modern form it comes down to three messages.
What the padlock really protects
HTTP, the protocol that serves websites, transmits content in plain text: any intermediate node the traffic passes through can read it. On top of that a security layer is added, TLS (Transport Layer Security), and the result is the HTTPS you see every day. TLS guarantees three things: confidentiality (only sender and receiver read the content), integrity (nobody can alter the data without it being detected) and authentication (the server really is who it claims to be, not an impostor). None of the three is trivial.
The problem of sharing a key without anyone seeing it
The most direct approach would be for both sides to use the same key to encrypt and decrypt, the so-called symmetric encryption (a single shared key). But how do they exchange it without an intermediary capturing it? That is where asymmetric cryptography, or public-key cryptography, comes in: each party has a key pair, a public one that can be distributed and a private one that is never shared. What one encrypts, only the other can decrypt.
For years the exchange was done with RSA, where the client encrypted a secret with the server’s public key and only the server, with its private key, could recover it. The problem is that if someone stole that private key years later, they could decrypt all previously recorded traffic. To prevent this, Diffie-Hellman over elliptic curves, ECDHE, was introduced: both sides generate ephemeral keys (disposable, single-use) that are combined mathematically to derive a shared secret. Because those keys are destroyed when the session ends, even if the server is compromised in the future, previously recorded data cannot be read. This is the principle of forward secrecy.
The handshake in TLS 1.3
The protocol is now 26 years old, and version 1.3 (ratified in 2018) drastically simplified the process. Compared with the two round trips of TLS 1.2, here three messages and a single round trip (1-RTT) are enough. This is how it unfolds:
1) ClientHello. The browser greets: it proposes the TLS versions it supports, the available encryption algorithms (cipher suites) and, in passing, generates its ephemeral part for the ECDHE exchange.
2) ServerHello. The server replies by choosing version and algorithms, contributes its own ephemeral key and sends its digital certificate: a document that ties its identity to a public key. All the content of this message is digitally signed so the client can verify it has not been tampered with.
3) Finished. With the pieces from both sides, browser and server each compute the same session secret separately and confirm it. From then on they switch to symmetric encryption with fast algorithms such as AES-GCM (which encrypts and authenticates at once, in AEAD mode), because asymmetric crypto would be far too slow for real traffic.
Thanks to this optimization, resuming a connection with a server you already know can happen even without waiting for a reply, with 0-RTT: the client reuses the stored secret and already sends the first data encrypted. The trade-off is weaker protection against message replay, a risk the protocol accepts in exchange for speed.
Certificates: the chain of trust
That the server sends a certificate is not enough: anyone can generate one. The key is that this certificate carries the signature of a certification authority (CA), an entity your operating system already trusts. Your browser checks the signature, follows the chain of trust from the root CA down to the server’s certificate and also validates that it is for that domain and that it has not expired or been revoked. If any link fails, you will see the dreaded insecure-connection warning.
A protocol that is no longer only for websites
That same TLS has become the security foundation of almost everything: email, VPNs, messaging and, notably, QUIC, the transport protocol of HTTP/3, which embeds the TLS 1.3 handshake inside its own messages instead of adding it afterwards. And certificates are being pushed towards a shorter life: the fewer days they live, the smaller the window for a stolen certificate to be useful. The padlock you see in your browser today is, at its core, the result of a mathematical choreography designed so that trusting does not have to be an act of faith.
