What Happens During an HTTPS Handshake

The padlock in your browser's address bar represents a brief negotiation that happens before any webpage data is transferred — the TLS handshake. It's over in milliseconds, but it's doing three distinct jobs at once.

Job one: prove identity

The server presents a certificate, issued by a certificate authority your browser already trusts, proving "this really is example.com." Your browser checks the certificate's signature chain back to a trusted root — this is what stops someone from silently impersonating a site you think you're talking to.

Job two: agree on a shared secret

Public-key cryptography (the same family of math behind SSH keys) is used briefly to let your browser and the server agree on a secret key — without ever sending that key across the network in a form an eavesdropper could read. This step is where the actual asymmetric encryption happens; everything after it switches to something faster.

Job three: switch to fast encryption

Public-key cryptography is secure but slow for bulk data. Once both sides share the secret from step two, they switch to symmetric encryption — much faster — for the rest of the session. That shared secret is what actually encrypts your requests and the page content coming back.

Browser → "Hello, here's what I support"
Server  → Certificate + "let's agree on a secret"
Browser → verifies certificate, helps derive the secret
Both    → switch to fast, symmetric encryption for the real traffic

What the padlock is actually promising

Two things only: the connection is encrypted in transit, and you're talking to whoever the certificate says you are. It says nothing about whether that site is trustworthy or safe to use — a phishing site can have a perfectly valid certificate for its own fake domain.