You type a website address, hit Enter, and the page starts loading. Before the browser sends anything important, though, it needs to establish a secure connection with the server. That setup is called a TLS handshake.

The Browser Says Hello

The handshake starts with the browser sending a ClientHello message to the server. Think of it as the browser saying, “I want to talk securely. Here are the security options I support.”

The message includes the TLS version it supports. It also contains information needed to choose a secure connection. The browser sends a random value too, which becomes part of the material used during the handshake.

Then the server responds with ServerHello. It picks the TLS version and cryptographic options that both sides can use. The server also sends its certificate, which proves that the server has a valid identity for the website you’re visiting.

The Certificate Gets Checked

This is where your browser becomes a little suspicious. And that’s good.

A TLS certificate contains the website’s identity and is issued by a trusted Certificate Authority. Your browser checks whether the certificate is valid and whether it matches the website you’re trying to reach. It also checks whether the certificate has expired or failed other trust checks.

If everything looks right, the browser continues. If something looks seriously wrong, you’ll usually get a security warning instead of a quiet connection.

Why Trust Matters

Imagine Raj opens his bank’s website during his morning commute. He usually has Spotify playing while he works through email, so he barely notices the page loading. The TLS handshake happens in the background, and he stops reopening the same five tabs every morning just to check whether the connection looks secure.

The certificate is a big reason this works. Encryption alone doesn’t prove who you’re talking to. You could have a perfectly encrypted connection to the wrong server, which would be a pretty useless victory.

Both Sides Create Secret Keys

Once the server’s identity is accepted, the browser and server need a shared secret for encrypting the actual conversation.

Modern TLS normally uses an ephemeral key exchange. Each side creates temporary key information and exchanges what it needs to calculate the same shared secret without sending that secret across the network.

The important part is this: someone watching the connection can see the handshake traffic, but they shouldn’t be able to calculate the final shared secret from it.

Then Encryption Takes Over

After the shared keys are established, both sides confirm that the handshake completed correctly. From there, application data can travel through the encrypted TLS connection.

• The browser has verified the server’s identity, which is the bit that stops encryption from becoming security theatre.

• A shared secret now exists on both ends, although it was never simply sent from one machine to the other.

• The connection switches to encrypted application traffic, and this is where the handshake starts feeling invisible.

Why TLS Feels So Fast

A TLS handshake involves real cryptography and several messages. Still, modern TLS is designed to keep the process short. TLS 1.3 reduced the number of round trips needed to establish a secure connection, which matters when the server is far away.

So when a website feels almost instant after you click it, there’s a lot happening before the first useful piece of encrypted data reaches you.

And once that handshake is finished, your browser doesn’t need to keep asking, “Can I trust this connection?” It simply gets on with the job.