When you open a web page, there is an invisible moment in which your browser and the server shake hands and agree on how to talk without anyone else being able to listen. That moment is the TLS handshake, the cryptographic handshake that underpins the green padlock in your address bar. Today we are going to open the door and see what is inside.
Two cryptographic worlds that complement each other
All the cryptography that protects the internet rests on two families of algorithms. Symmetric cryptography uses a single secret key to encrypt and decrypt: it is extremely fast, but requires sender and receiver to share that key without anyone intercepting it. Asymmetric cryptography (or public-key cryptography) uses a pair of mathematically related keys: a public one, which anyone can see, and a private one, known only to its owner. It is slow, but it solves the problem of sharing secrets over an insecure channel.
TLS does not choose between one and the other: it combines them. The asymmetric part serves to securely exchange a session key, and with that symmetric key the page’s real traffic is encrypted. Thus you get the speed of symmetric encryption with the security of asymmetric.
The handshake, step by step
In TLS 1.3, the most recent protocol and the one used by most of today’s web traffic, the handshake is reduced to two round trips (in TLS 1.2 it was four). The browser sends a ClientHello message with the algorithms it supports. The server responds with its ServerHello, chooses the common algorithm and sends its digital certificate.
The certificate is the key piece of trust: it contains the site’s public key and the signature of a certificate authority (CA), an accredited entity such as Let’s Encrypt or DigiCert. The browser verifies that signature using the CA’s public key, which already comes installed in your operating system. If the signature is valid and the certificate is within its validity period, the browser knows it is talking to the correct site.
Forward secrecy: even if they spy on you, they will not read the old stuff
To derive the session key, TLS 1.3 uses ECDHE (Diffie-Hellman over elliptic curves), a key exchange that generates a shared secret without it ever travelling over the network. Its most valuable property is forward secrecy: each session uses ephemeral keys that are destroyed when it ends. Even if an attacker recorded all your traffic today and stole the server’s private key tomorrow, they could not decrypt what they recorded. That is why older protocols without this property (such as the first version of TLS) are considered obsolete.
The actual encryption of traffic
With the session key established, the data phase begins. TLS splits the flow into blocks called TLS records and encrypts them with an authenticated symmetric cipher, usually AES-256-GCM or ChaCha20-Poly1305. The GCM and Poly1305 part is key: they not only hide the content, they also authenticate it, guaranteeing that nobody has altered or reordered the packets along the way. If a single byte is tampered with, the receiver detects it and discards the connection.
In addition, each record carries its sequence number, which prevents replay attacks in which an attacker reintroduces a previously captured message to confuse the receiver. Encryption, authentication and integrity work together in a single layer.
And what about the site itself?
It is important to separate two things: TLS encrypts the channel between your browser and the server, but it does not protect the data once it reaches the server, nor does it guarantee that the server is honest. The padlock means “nobody is listening along the way”, not “this site is trustworthy”. That is why encryption is always accompanied by other layers: the certificate’s identity verification, the page’s policy and the site’s own code.
The next time you see the padlock, you will know that behind it elliptic curves, ephemeral keys and authenticated encryption are working in milliseconds to make your conversation with the web yours and nobody else’s.
