Introduction

If I mail you a locked box, and you don’t have the key, how do we open it? If I mail you the key, the mailman copies it.

This is the fundamental problem of cryptography: Key Exchange. TLS (Transport Layer Security) solves it using math that makes “mixing colors” easy, but “un-mixing” them impossible.

In this lesson, we dissect the handshake that secures 99% of the web.

---

The Physics: Diffie-Hellman (ECDHE)

The Goal: Agree on a shared number (Session Key) without ever sending it over the wire.

The Paint Metaphor:

1. Public: We agree on a common color (Yellow).
2. Private: I pick Red. You pick Blue.
3. Mix: I mix Yellow+Red (Orange). You mix Yellow+Blue (Green).
4. Exchange: I send you Orange. You send me Green.
5. Final Mix:
   • I take your Green + my Red = Brown.
   • You take my Orange + my Blue = Brown.

We both have “Brown”. The mailman only saw Yellow, Orange, and Green. He cannot make Brown without Red or Blue.

In Math (Elliptic Curves): $SharedSecret = d_A \times (d_B \times G) = d_B \times (d_A \times G)$ Where $G$ is the Generator Point on the curve.

---

The Evolution: Forward Secrecy (PFS)

In the old days (RSA Key Exchange), the client encrypted the Session Key with the Server’s Public Key. The Flaw: If the NSA steals the Server’s Private Key 5 years from now, they can decrypt all past traffic recorded today.

The Fix: Ephemeral Keys (DHE/ECDHE). We generate new Red/Blue colors for every single connection. If the Server’s key is stolen, it proves identity, but it cannot decrypt traffic. The session keys are gone forever.

---

Speed: TLS 1.2 vs 1.3

Latency matters. Every round trip is 50-100ms.

TLS 1.2 (2-RTT)

1. Client: “Hello”
2. Server: “Hello + Certificate”
3. Client: “Key Exchange”
4. Server: “Finished”
5. Data Transmission begins.

TLS 1.3 (1-RTT)

The Client guesses the Server’s key exchange settings and sends its “Mix” immediately.

1. Client: “Hello + My Key Share”
2. Server: “Hello + My Key Share + Finished”
3. Data Transmission begins.

0-RTT: If I visited you before, I remember the key, and I send encrypted data in the very first packet.

---

Deep Dive: The Chain of Trust

Why trust google.com? Because DigiCert signed it. Why trust DigiCert? Because it is in your OS’s Root Store.

The Danger: If a Root CA is hacked or coerced, they can mint a valid certificate for google.com, and your browser will accept it. (This happened with DigiNotar).

---

Code: Inspecting Certs

Do not use a browser. Use openssl.

# S_CLIENT: The Swiss Army Knife of TLS
openssl s_client -connect google.com:443 -showcerts

# Output Analysis:
# 1. Server Certificate (Subject: google.com)
# 2. Intermediate Certificate (Issuer: GTS CA 1C3)
# 3. Root Certificate (Usually locally operational, not sent)

---

Practice Exercises

Exercise 1: The Man-in-the-Middle (Beginner)

Scenario: You are on public WiFi. Attacker sends you their key instead of the server’s. Task: How does the “Certificate” prevent you from accepting the Attacker’s key? (Hint: Signatures).

Exercise 2: Session Resumption (Intermediate)

Scenario: You reconnect to a server after 5 minutes. Task: Explain “Session Tickets”. How does this avoid doing the heavy ECDH math again?

Exercise 3: Decrypting Traffic (Advanced)

Task:

1. Set SSLKEYLOGFILE environment variable in Chrome.
2. Capture traffic with Wireshark.
3. Load the key log file into Wireshark to decrypt HTTPS traffic. (Note: This proves that with the Session Keys, secrecy is broken).

---

Knowledge Check

1. Why is Forward Secrecy critical for privacy?
2. What is the difference between the “Handshake” and the “Record” protocol?
3. Why does TLS 1.3 remove RSA Key Exchange?
4. What is SNI (Server Name Indication)?
5. Does TLS hide the hostname you are visiting?

Answers

1. Future-proofing. It ensures that a future server compromise does not compromise past data.
2. Handshake = Agreeing on keys (Asymmetric). Record = Sending data (Symmetric/AES).
3. No PFS. RSA Key Exchange does not support Forward Secrecy.
4. Routing. Client tells the server which domain it wants (in plaintext) so the server can serve the right certificate (Virtual Hosting).
5. No. SNI is plaintext (until ECH - Encrypted Client Hello becomes standard). Your ISP knows where you are going.

---

Summary

• Diffie-Hellman: Magic math for sharing secrets.
• Certificates: Only solve the “Who are you?” problem.
• TLS 1.3: Faster and more secure by deleting old features.

---