How the TLS 1.2 Handshake Works — A Simple Step-by-Step Guide

Most people know the little s in https:// stands for “secure”, but what actually makes it secure? The answer is TLS (Transport Layer Security), the protocol that encrypts and protects your connection.

Whenever you visit a site over HTTPS, your browser and the server first need to agree on how to talk securely. That’s where the TLS handshake comes in. Here’s how it works in TLS 1.2, step by step.

Before TLS: TCP (Transmission Control Protocol)

TLS doesn’t work alone. First, a reliable connection is set up with the standard TCP three-way handshake (SYN → SYN-ACK → ACK). Once that’s done, the TLS handshake begins.

Step 1: ClientHello (client → server)

The client (your browser) starts the process by sending:

• Supported TLS versions
• A list of cipher suites (encryption options)
• Extra information like SNI (Server Name Indication) or ALPN (for HTTP/2 support).

Step 2: ServerHello + Certificate (server → client)

The server replies with:

• Its chosen cipher suite
• A digital certificate, which includes the server’s public key and information about the server itself.

Step 3: Certificate Validation (client side)

The client checks the server’s certificate:

• The certificate is signed by a Certificate Authority (CA). Meaning that the certificate is encrypted by CA’ s Private Key and can be only decrypted by CA’ s Public Key. In most of the cases signature is the encrypted hash-code of the certificate.
• If the client was able to decrypt the certificate using CA’ s Public Key, it knows two things:

1. The certificate really came from that CA (authenticity).

2. The certificate hasn’t been tampered with (integrity).

At this point, the client trusts the server’s public key.

Step 4: Key Exchange (RSA example)

The client generates a pre-master secret, encrypts it with the server’s public key, and sends it back.

Step 5: Session Key Generation

The server decrypts the pre-master secret using its private key. Now, both client and server have the same pre-master secret, which they use to generate identical session keys locally.

👉 These session keys are never transmitted — they’re derived independently on both sides.

Step 6: Secure Data Exchange

From here on, all communication is encrypted using the session keys. This is symmetric encryption, which is fast and efficient.

🎉 Wrapping It Up

So, every time you see that little lock icon in your browser, remember: under the hood, your browser and the server just went through a careful dance of handshakes, checks, and key exchanges. Thanks to TLS, your messages stay private, authentic, and tamper-free — all in just a fraction of a second. Not only HTTPS but also SMTP and LDAP and many other protocols use TLS for secure data transmission.