AHMED ZBYR

AHMED ZBYR

Biker, EV Enthusiast

Every time you log into your bank, buy something online, or even read a blog post, your browser quietly turns a regular web connection (HTTP) into a fortified, encrypted tunnel (HTTPS)—all in less than a tenth of a second.

Most people know that the little padlock icon in the address bar means “this connection is encrypted.” Today, though, let’s answer the far more interesting question:

How can your browser and a website server—two complete strangers separated by thousands of miles and dozens of untrusted routers—agree on a secret encryption key when hackers can listen to every single packet they send to each other?

In this post, we will start with a simple everyday puzzle and build upon it step-by-step until you understand every single message inside a real HTTPS / TLS Handshake.

Level 1: Why Plain HTTP Is Like Sending a Postcard

When you visit an old http:// website (without the S for Secure), every message your browser sends is like writing on the back of a paper postcard and dropping it in the mail.

Before that postcard reaches the website’s server, it passes through:

  1. The Wi-Fi router in your coffee shop, hotel, or home.
  2. Your Internet Service Provider (ISP).
  3. Dozens of intermediary routers and undersea cables across the globe.

Anyone sitting along that path can do three dangerous things to a paper postcard:

  • Eavesdrop (No Privacy): Read your password, credit card number, or private messages right off the card.
  • Tamper (No Integrity): Erase $10.00 on the postcard and write $10,000.00—or inject malicious ads and scripts into the web page before it reaches your screen.
  • Impersonate (No Identity): Throw your postcard in the trash and mail you back a fake postcard pretending to be your bank.

HTTPS (HTTP over TLS — Transport Layer Security, formerly called SSL) solves all three problems at once by locking the postcard inside an indestructible steel box before it ever leaves your computer.

Level 2: The Stranger’s Dilemma (How Do We Share a Key?)

To lock messages inside a digital steel box, computers use Symmetric Encryption (like AES-256).

  • How Symmetric Encryption works: Your browser and the server both have a copy of the exact same Secret Key. Your browser uses that key to scramble (encrypt) your password into gibberish, and the server uses the same key to unscramble (decrypt) it.

Wait—Here Is the Catch!

If your browser in London invents a brand-new Secret Key to talk to a server in New York, how does your browser send that Secret Key to the server?

If your browser simply sends the Secret Key over the internet, a hacker listening on the coffee-shop Wi-Fi will copy the key too—and unlock every message you send!

How can two strangers create a shared secret key while shouting across a crowded room full of eavesdroppers?

The Solution: The Paint-Mixing Trick (Diffie–Hellman Key Exchange)

In the 1970s, Whitfield Diffie and Martin Hellman discovered a mathematical miracle that works just like mixing cans of paint.

Imagine one simple rule about paint:

  • Mixing two colors together is super easy.
  • Un-mixing a blended paint back into its original colors is impossible!

Now watch how Alice (your Browser) and Bob (the Website Server) create a shared secret color right in front of a Hacker sitting between them:

1. PUBLIC STARTING COLOR:
   Alice and Bob publicly agree to start with a bucket of YELLOW paint.
   (The Hacker hears this and also gets a bucket of Yellow.)

2. SECRET COLORS (Never Sent Over the Internet!):
   - Alice secretly picks RED paint.
   - Bob secretly picks BLUE paint.

3. MIX AND SWAP IN PUBLIC:
   - Alice mixes Yellow + Red  = ORANGE, and sends ORANGE to Bob.
   - Bob mixes   Yellow + Blue = TEAL,   and sends TEAL to Alice.
   (The Hacker intercepts both ORANGE and TEAL, but can't un-mix them!)

4. THE FINAL SECRET MIX:
   - Alice pours her secret RED into Bob's TEAL:
     (Yellow + Blue) + Red  = SECRET BROWN!
   - Bob pours his secret BLUE into Alice's ORANGE:
     (Yellow + Red)  + Blue = SECRET BROWN!

Look at what just happened:

  • Alice and Bob now have the exact same Secret Brown color (Yellow + Red + Blue)—and they never had to send their secret colors across the room!
  • What does the Hacker have? The Hacker only has Yellow, Orange (Yellow + Red), and Teal (Yellow + Blue). Because the Hacker never got pure Red or pure Blue, the Hacker cannot make the exact Yellow + Red + Blue mixture!

In real HTTPS connections, instead of cans of paint, your browser and the server use one-way mathematical curves called ECDHE (Elliptic Curve Diffie–Hellman Ephemeral) to create a shared Session Key in a few milliseconds.

Level 3: Wait—How Do You Know Bob Isn’t an Impostor? (Certificates)

The Paint-Mixing Trick is brilliant, except for one sneaky loophole:

What if the Hacker intercepts Alice’s message and pretends to be Bob—mixing paint with Alice on one side and mixing paint with the real Bob on the other side (a Man-in-the-Middle Attack)?

Alice needs proof that the server on the other end is genuinely yourbank.com and not an impostor.

The Digital Passport (TLS / SSL Certificate)

In the real world, how do you prove who you are at an airport? You show a Government Passport:

  • Anyone can print a piece of paper that says “Name: YourBank.”
  • What makes a passport trustworthy is the unforgeable holographic stamp from a governmentPassport Agency that you already trust.

On the internet, websites use Digital Certificates (often called SSL/TLS Certificates):

  1. Before yourbank.com goes live, it proves to a trusted Certificate Authority (CA) (such as Let’s Encrypt, DigiCert, or Cloudflare) that it really owns the domain yourbank.com.
  2. The Certificate Authority issues yourbank.com a Digital Certificate containing:
    • The domain name (yourbank.com)
    • The server’s official Public Key
    • The Certificate Authority’s unforgeable Digital Signature
  3. Your browser (Chrome, Safari, Firefox) and operating system come with the official verification keys of trusted Certificate Authorities pre-installed from the factory.

When you connect to https://yourbank.com, the server shows its Certificate (Passport), and demands: “Challenge me!” Your browser verifies the Certificate Authority’s stamp, and checks the server’s Digital Signature (which can only be created by the holder of yourbank.com’s secret Private Key). An impostor without yourbank.com’s Private Key fails this check instantly—triggering that giant red “Your connection is not private” warning screen in your browser!

Level 4: Step-by-Step Walkthrough of the TLS Handshake

Now let’s put all the pieces together!

When you type https://example.com and press Enter, before a single word of the web page or your password is sent, your browser and the server perform a lightning-fast greeting called the TLS Handshake (shown here for modern TLS 1.3):

sequenceDiagram
    autonumber
    participant C as Browser (Client)
    participant S as Web Server (example.com)

    Note over C,S: Phase 1: TCP Connection (Picking up the phone)
    C->>S: TCP SYN
    S->>C: TCP SYN-ACK
    C->>S: TCP ACK

    Note over C,S: Phase 2: The TLS 1.3 Handshake (~1 Round Trip!)
    C->>S: ClientHello (Supported Ciphers + Browser's Public Key Share "Orange Paint")
    S->>C: ServerHello (Chosen Cipher + Server's Public Key Share "Teal Paint")
    Note over C,S: Both sides now calculate the shared Secret Session Key!
    S->>C: Encrypted: Digital Certificate ("Passport") + Signature Proof + Server Finished
    Note over C: Browser verifies Certificate & Signature
    C->>S: Encrypted: Client Finished

    Note over C,S: Phase 3: Secure HTTPS Data Transfer (Fast AES/ChaCha20 Encryption)
    C->>S: Encrypted HTTP Request: GET /login (Passwords, Cookies safe!)
    S->>C: Encrypted HTTP Response: 200 OK (HTML Page)

If your reader does not render Mermaid diagrams, here is the exact same handshake step-by-step in plain text:

BROWSER (Client)                                     WEB SERVER (example.com)
================                                     ========================
  |                                                             |
  |--- 1. TCP Handshake (SYN -> SYN-ACK -> ACK) --------------->| (Opens network pipe)
  |                                                             |
  |--- 2. ClientHello ----------------------------------------->|
  |    "Hi! I support TLS 1.3 and AES-256-GCM.                  |
  |     Here is my public key share ('Orange Paint')."          |
  |                                                             |
  |<-- 3. ServerHello + Certificate + Signature ----------------|
  |    "Great, let's use TLS 1.3 + AES-256-GCM!                 |
  |     Here is my public key share ('Teal Paint').             |
  |     [Both sides now mix the shared Secret Session Key!]     |
  |     Here is my Certificate ('Passport') and my digital      |
  |     signature proving I really own example.com."            |
  |                                                             |
  | [4. Browser checks Certificate stamp & signature -> VALID!] |
  |                                                             |
  |--- 5. Client Finished (Encrypted with Session Key) -------->|
  |                                                             |
=============================================================================
        SECURE TUNNEL ESTABLISHED! (Padlock Icon Appears in Browser)
=============================================================================
  |                                                             |
  |<== 6. Encrypted HTTP Traffic (GET /index.html, Passwords) =>|

Let’s review what each step in that handshake accomplished:

  1. Step 1 (TCP Handshake): Like dialing a phone number and hearing the other side pick up so both computers know the network wire is connected.
  2. Step 2 (ClientHello): Your browser introduces itself, lists which encryption recipes (Cipher Suites) it knows, and sends its half of the Diffie–Hellman paint mix.
  3. Step 3 (ServerHello + Certificate + Signature):
    • The server picks the strongest encryption recipe both sides support.
    • The server sends its half of the Diffie–Hellman paint mix. At this exact moment, both the browser and the server can calculate the shared Symmetric Session Key!
    • Using that new Session Key, the server sends its Digital Certificate and a Cryptographic Signature over the handshake transcript proving it really owns the domain’s Private Key.
  4. Step 4 & 5 (Verification & Finished): Your browser checks the Certificate against its trusted Certificate Authorities, verifies the signature, and sends an encrypted Finished message.
  5. Step 6 (Encrypted HTTP): The handshake is complete! Now your browser sends your actual HTTP requests (GET, POST, cookies, passwords) locked with the fast Symmetric Session Key.

Level 5: Two Questions Every Curious Engineer Asks

1. Why Does HTTPS Use Two Types of Cryptography?

You might wonder: “If Public/Private Key cryptography (Asymmetric Cryptography) is so clever, why don’t we just use it to encrypt the entire Netflix movie?”

Because Asymmetric Cryptography requires heavy math that is roughly 100x to 1,000x slower than Symmetric Encryption!

  • During the Handshake (First ~20 milliseconds): HTTPS uses Asymmetric Cryptography (ECDHE + RSA/ECDSA signatures) to verify identity and safely agree on a shared key.
  • After the Handshake (All your actual data): HTTPS switches to Symmetric Authenticated Encryption (AES-GCM or ChaCha20-Poly1305), which modern CPUs can encrypt and decrypt at gigabytes per second with almost zero battery or CPU drain.

2. What Changed Between TLS 1.2 and TLS 1.3?

Feature TLS 1.2 (2008) TLS 1.3 (2018 — Modern Standard)
Handshake Speed 2 Round Trips (2-RTT) before sending data 1 Round Trip (1-RTT) (or 0-RTT when resuming a recent visit!)
Certificate Privacy Sent in plain text during the handshake Sent encrypted right after ServerHello
Forward Secrecy Optional (some servers used static RSA key exchange) Mandatory (ECDHE) — Every single connection gets a brand-new, disposable key!

Why Mandatory Forward Secrecy in TLS 1.3 Is Huge: Because TLS 1.3 generates a brand-new, throwaway Diffie–Hellman key for every single session and deletes it when you close the tab, even if a hacker records all your encrypted Wi-Fi traffic today and steals the website’s Private Key 10 years from now, they still can never decrypt your past sessions!

Watch a Real TLS Handshake Live in Your Terminal!

You don’t have to take our word for it—you can watch your own computer perform every step of the TLS Handshake right now by running curl -vI in your terminal:

curl -vI https://example.com

Look at the lines starting with * TLSv1.3 in the output:

* Connected to example.com (93.184.215.14) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=example.com
*  SSL certificate verify ok.
> GET / HTTP/2
< HTTP/2 200

Look how clean that is: Client hello → Server hello → Certificate → CERT verify → Finished → TLS_AES_256_GCM_SHA384—every single piece we just learned, happening right before your eyes in milliseconds!

References & Further Reading

  1. RFC 8446 (IETF): The Transport Layer Security (TLS) Protocol Version 1.3 (August 2018) — The official specification for modern TLS 1.3 handshakes and cryptographic negotiation.
  2. Diffie, W., & Hellman, M. (1976): “New Directions in Cryptography”, IEEE Transactions on Information Theory, 22(6), 644–654. The landmark paper that solved the key-exchange problem between strangers.
  3. Filippo Valsorda & Cloudflare Engineering: The Illustrated TLS 1.3 Connection (tls13.xargs.org) — An interactive byte-by-byte walkthrough of a real TLS 1.3 handshake.

You May Also Enjoy