TLS handshake

What your browser does in the split second before the padlock appears

Before HTTPS sends any page, browser and server run the TLS handshake: a few messages that agree on a secret key and prove the server is the site you typed. Only then does the padlock appear.

In TLS 1.3, the current version, your browser's first message (ClientHello) lists its ciphers, names the site and carries a key share: a public number from a fresh Diffie–Hellman key pair.

The server's reply (ServerHello) carries its own key share. From these two public numbers both sides compute the same secret, which an eavesdropper who saw both cannot work out.

TLS handshake

A laptop clock set years wrong breaks the padlock on every site

In the handshake the server sends its certificate: a document signed by a certificate authority saying this key belongs to example.com between two dates. Your browser checks the signature, name and dates.

If your clock says 2015, every modern certificate looks not yet valid, so the handshake fails and Chrome shows NET::ERR_CERT_DATE_INVALID instead of a padlock.

TLS handshake

The server signs the whole conversation, so no middleman can fake it

Key shares alone can't stop a middleman swapping in his own numbers. So the server signs a hash of the handshake so far (CertificateVerify) with its certificate's private key, which only the real site holds.

Each side then sends Finished, a keyed checksum (MAC) over every handshake message, so any tampering shows. Sending the key share up front makes all this one round trip; TLS 1.2 needed two.

Afterwards a and b are deleted, so someone who steals the server's private key later still can't decrypt recorded sessions. This is called forward secrecy.