SSL/TLS Handshake: Step-by-Step Explanation of How It Works

Spread the love
Step-by-step SSL/TLS handshake process between client and server with encryption, certificate exchange, and key generation

If you’ve ever visited a website that starts with https:// and noticed the little padlock icon in your browser, you’ve already experienced SSL/TLS in action. But what actually happens behind the scenes when your browser connects securely to a website?

Let’s break it down step by step — from the first “hello” to fully encrypted data transfer — so you understand exactly how the handshake works.

1. Step 1: Client Hello – Initiating the Conversation

The SSL/TLS process starts when your browser (the client) says “Hello” to the web server.
In this first message, the browser sends:

  • Supported protocol versions (e.g., TLS 1.3, TLS 1.2)
  • Supported cipher suites (list of possible encryption algorithms)
  • Compression methods (optional)
  • A random number (used later for key generation)

This is like a restaurant menu — the browser tells the server, “Here are the dishes (protocols and ciphers) I can work with.”

Detailed step-by-step SSL/TLS handshake diagram showing client-server communication, certificate verification, and key exchange

2. Step 2: Server Hello – Agreeing on the Rules

The server replies with its own “Hello” message, choosing:

  • The TLS version to use
  • The cipher suite for encryption
  • Another random number
  • Session ID (optional, for reusing sessions)

This is like the server saying, “Okay, let’s go with dish number 3 from your menu.”

3. Step 3: Server Certificate – Proving Its Identity

The server sends its digital certificate (usually an X.509 certificate). This certificate:

  • Contains the server’s public key
  • Is issued by a trusted Certificate Authority (CA)
  • Includes the server’s domain name and expiry date
  • Is signed by the CA’s private key

Your browser checks:

  • Is the certificate issued by a trusted CA?
  • Is the certificate still valid (not expired)?
  • Does the domain name match the certificate?

If any of these fail, you’ll see a security warning.

4. Step 4: Key Exchange – Setting Up a Shared Secret

Once the browser trusts the certificate, the key exchange happens. There are two main methods:

a) RSA (older method)
– Browser generates a pre-master secret.
– Encrypts it with the server’s public key from the certificate.
– Sends it to the server, which decrypts it using its private key.

b) Diffie–Hellman / ECDHE (modern method)
– Both sides exchange special values to generate a shared secret without ever sending it directly.
– This provides Perfect Forward Secrecy (PFS), meaning past sessions can’t be decrypted even if the private key is later compromised.

5. Step 5: Generating the Session Keys

Both the client and server now have the same pre-master secret and the two random numbers from Step 1 and Step 2.
They use these values to:

  • Run them through a key derivation function
  • Create symmetric session keys for:
    • Encrypting data
    • Verifying integrity (MAC keys)

Symmetric encryption is much faster than asymmetric encryption, which is why it’s used for the actual data transfer.

6. Step 6: Finished Messages – Locking the Channel

– The browser sends an encrypted “Finished” message to confirm all steps are done correctly.
– The server replies with its own encrypted “Finished” message.

At this point, both sides are ready for secure communication.

7. Step 7: Encrypted Data Transfer

From here on:

  • All data is encrypted using the session key.
  • The same key is used for encryption and decryption (symmetric encryption).
  • Messages also include a Message Authentication Code (MAC) to ensure data isn’t altered.

Example in Real Life

Imagine sending a letter in a locked box.
– You (browser) ask the other person (server) what type of lock they use.
– They tell you, and also send their key’s public part.
– You create a small master key, lock it in a box with their public key, and send it.
– They open it with their private key.
– Now you both have the same master key to lock and unlock future letters instantly.

Why This Process Matters

Encryption ensures nobody can read the data in transit.
Authentication ensures you’re talking to the real website, not an imposter.
Integrity ensures the data isn’t changed on the way.

Without this handshake, sensitive information like passwords, credit card details, and personal messages could be intercepted by attackers.

Pro Tip: Modern browsers and servers use TLS 1.3, which shortens the handshake to just one round trip, making it faster and more secure.


Scroll to Top