Module 15 – BONUS: The TCP and TLS Handshake Explained Simply
+==============================================================================+
| MODULE 15 (BONUS): TCP + TLS HANDSHAKE (HTTPS) |
| Estimated Duration: 1 hour | Level: Absolute Beginner |
+==============================================================================+
Table of Contents
- Why this page?
- Basic Vocabulary – TCP "Flags"
- The 3-Step TCP Handshake (SYN / SYN-ACK / ACK)
- What happens after the handshake? Data exchanges (PSH, ACK)
- How do we close the connection? (FIN / FIN-ACK)
- Complete Recap of a TCP Connection
- The TLS Handshake – Adding the Padlock
- Concrete Example: Opening https://google.com
- What You See in Wireshark
- Final Summary – The Complete Analogy
Why this page?
When you open a website, your browser and the server communicate. But before exchanging anything, they must:
- Verify they can communicate (TCP handshake)
- Agree on how to encrypt (TLS handshake, if HTTPS)
- Exchange data (the web page)
- Hang up properly (connection closure)
All these exchanges use small flags in the network packets. That's what we'll explain here, as if you've never done networking before.
Basic Vocabulary – TCP "Flags"
Imagine each network message is a letter sent by mail. On each envelope, there are one or more stamps (flags) indicating what type of message it is.
Here are the main TCP flags:
| Flag | Full Name | Simple Analogy | Technical Meaning |
|---|---|---|---|
| SYN | Synchronize | 📞 "Hello? Are you there?" | "I want to open a connection" |
| ACK | Acknowledge | ✅ "Received!" | "I received your message" |
| PSH | Push | 📦 "Here's the package, open it right away!" | "Here is data, process it immediately" |
| FIN | Finish | 👋 "Goodbye, I'm hanging up" | "I want to close the connection" |
| RST | Reset | ❌ "STOP! Hung up forcefully!" | "Connection canceled/refused abruptly" |
The most important to remember
- SYN = "I want to start"
- ACK = "I understand/received"
- PSH = "here's the real data"
- FIN = "I'm done, goodbye"
The 3-Step TCP Handshake (SYN / SYN-ACK / ACK)
The Phone Analogy
Imagine you're calling a friend:
┌─────────────────────────────────────────────────────────────────────┐
│ PHONE CALL │
│ │
│ You (Client) Your friend (Server) │
│ │
│ 1. 📞 "Hello? Can you hear me?" ──────► │
│ (The phone rings) │
│ │
│ ◄────── 2. 📞 "Yes, I can hear you! │
│ Can you hear me?" │
│ │
│ 3. 📞 "Yes perfect, we can talk!" ──────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ ✅ CONVERSATION ESTABLISHED — You can chat! │
└─────────────────────────────────────────────────────────────────────┘
The Same in TCP
┌─────────────────────────────────────────────────────────────────────┐
│ TCP HANDSHAKE (3-WAY HANDSHAKE) │
│ │
│ Client (your PC) Server (e.g., google.com) │
│ │
│ STEP 1: SYN │
│ ──────────────────────────────────────► │
│ "I want to connect. My starting │
│ sequence number is 100." │
│ │
│ STEP 2: SYN-ACK │
│ ◄────────────────────────────────────── │
│ "OK, I accept (ACK your 100). │
│ My sequence number is 300." │
│ │
│ STEP 3: ACK │
│ ──────────────────────────────────────► │
│ "Perfect, received (ACK your 300). │
│ We can start!" │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ ✅ TCP CONNECTION ESTABLISHED │
│ ❌ But NOTHING is encrypted yet! │
└─────────────────────────────────────────────────────────────────────┘
Why 3 Steps and Not 1?
It's to verify that communication works both ways:
| Step | Proves that... |
|---|---|
| SYN (Client → Server) | The client can send to the server |
| SYN-ACK (Server → Client) | The server received AND can respond |
| ACK (Client → Server) | The client received the server's response |
Without these 3 steps, we wouldn't know if both machines truly understand each other.
What happens after the handshake? Data exchanges (PSH, ACK)
Once the connection is open, the real data flows. This is where we see PSH and ACK:
The Package Delivery Analogy
┌─────────────────────────────────────────────────────────────────────┐
│ DATA EXCHANGE (after the handshake) │
│ │
│ Client (browser) Server (website) │
│ │
│ 📦 PSH,ACK: "Here's my request: │
│ I want the homepage" ──────────────► │
│ (= HTTP GET request /) │
│ │
│ ◄────────────── ✅ ACK: │
│ "Received your request" │
│ │
│ ◄────────────── 📦 PSH,ACK: │
│ "Here's the HTML page!" │
│ (= HTTP 200 OK response) │
│ │
│ ✅ ACK: "Received the page, │
│ thank you!" ──────────────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 📄 The page displays in your browser! │
└─────────────────────────────────────────────────────────────────────┘
Why PSH + ACK Together?
You'll often see PSH,ACK in Wireshark (both flags at the same time). It's normal:
| Flag | Role in this packet |
|---|---|
| PSH | "Here is data, process it right away" |
| ACK | "By the way, I received your previous messages" |
PSH = "I'm sending a package"
ACK = "And I'm acknowledging receipt of what you sent before"
Both together = efficiency: we do two things in one packet!
And if we don't use PSH?
Without PSH, data arrives but the system might wait before processing it (it buffers it). With PSH, it's "process this immediately!"
Think of the difference between:
- 📬 Putting a letter in the mailbox (without PSH → the mailman will process it when he wants)
- 🚨 Ringing the doorbell and saying "it's urgent, read it right away!" (with PSH)
How do we close the connection? (FIN / FIN-ACK)
When the conversation is over, we hang up properly:
┌─────────────────────────────────────────────────────────────────────┐
│ CONNECTION CLOSURE (4-WAY) │
│ │
│ Client Server │
│ │
│ 👋 FIN,ACK: "I'm done, │
│ I want to hang up" ──────────────► │
│ │
│ ◄────────────── ✅ ACK: │
│ "OK, understood" │
│ │
│ ◄────────────── 👋 FIN,ACK: │
│ "I'm done too" │
│ │
│ ✅ ACK: "OK, goodbye!" ──────────────► │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 🔌 CONNECTION CLOSED PROPERLY │
└─────────────────────────────────────────────────────────────────────┘
And RST in all this?
RST (Reset) is when we hang up abruptly, without saying goodbye:
| Situation | What happens |
|---|---|
| The port is closed on the server | The server responds RST → "This service doesn't exist!" |
| The firewall blocks the connection | Either RST, or no response at all (timeout) |
| The application crashes | The system sends RST to cut the connection |
FIN = hang up politely 👋
RST = slam the phone down ❌
Complete Recap of a TCP Connection
Here's the entire lifecycle of a TCP connection, from start to finish:
┌─────────────────────────────────────────────────────────────────────┐
│ COMPLETE LIFECYCLE OF A TCP CONNECTION │
│ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ PHASE 1: OPENING (3-way handshake) ║ │
│ ║ ║ │
│ ║ Client ──── SYN ────────► Server ║ │
│ ║ Client ◄─── SYN,ACK ──── Server ║ │
│ ║ Client ──── ACK ────────► Server ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ PHASE 2: DATA EXCHANGE ║ │
│ ║ ║ │
│ ║ Client ──── PSH,ACK ───► Server (request) ║ │
│ ║ Client ◄─── ACK ──────── Server (acknowledgment) ║ │
│ ║ Client ◄─── PSH,ACK ──── Server (response) ║ │
│ ║ Client ──── ACK ────────► Server (acknowledgment) ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │ │
│ ▼ │
│ ╔═══════════════════════════════════════════════════════════╗ │
│ ║ PHASE 3: CLOSURE (4-way) ║ │
│ ║ ║ │
│ ║ Client ──── FIN,ACK ───► Server ║ │
│ ║ Client ◄─── ACK ──────── Server ║ │
│ ║ Client ◄─── FIN,ACK ──── Server ║ │
│ ║ Client ──── ACK ────────► Server ║ │
│ ╚═══════════════════════════════════════════════════════════╝ │
│ │
│ 🏁 END — Connection properly terminated │
└─────────────────────────────────────────────────────────────────────┘
The TLS Handshake – Adding the Padlock
When does TLS intervene?
TLS is placed between the TCP handshake and the data:
Step 1: TCP Handshake → "We open the door"
Step 2: TLS Handshake → "We add the padlock + verify identity"
Step 3: Encrypted Data → "We talk, but no one can listen"
The Bank Analogy
Imagine you want to send a secret message to your bank:
┌─────────────────────────────────────────────────────────────────────┐
│ TLS HANDSHAKE (simplified) │
│ │
│ You (Client) The Bank (Server) │
│ │
│ STEP 1 — ClientHello │
│ ──────────────────────────────────────► │
│ "Hello! I want to communicate secretly. │
│ Here are the encryption methods I know: │
│ AES-256, ChaCha20, etc." │
│ │
│ STEP 2 — ServerHello + Certificate │
│ ◄────────────────────────────────────── │
│ "OK! We'll use AES-256. │
│ And here's my ID CARD (certificate): │
│ - I am indeed 'National Bank' │
│ - Signed by a trusted authority (Let's Encrypt, etc.) │
│ - Valid until 2026-12-31" │
│ │
│ STEP 3 — Verification (client side) │
│ 🔍 You verify the ID card: │
│ ✅ Does the name match the site? │
│ ✅ Signed by a recognized authority? │
│ ✅ Not expired? │
│ → If everything is OK, we continue. Otherwise = certificate error. │
│ │
│ STEP 4 — Key Exchange │
│ ──────────────────────────────────────► │
│ 🔐 The client and server agree on a │
│ SHARED SECRET (without ever sending it in clear!) │
│ Method: Diffie-Hellman or similar. │
│ │
│ Analogy: imagine you each mix a color │
│ of paint in secret. You exchange the result, │
│ and you both arrive at the SAME final color, │
│ but someone watching cannot guess it. │
│ │
│ STEP 5 — Finished │
│ ◄─────────── (both sides) ──────────► │
│ "We have the same secret keys. │
│ From now on, EVERYTHING is encrypted!" │
│ │
│ ═══════════════════════════════════════════════════════════════ │
│ 🔒 TLS TUNNEL ESTABLISHED — All communication is encrypted! │
└─────────────────────────────────────────────────────────────────────┘
Frequently Asked Questions
What is a certificate?
It's the server's digital ID card. It contains:
- The site's name (e.g.,
google.com) - The server's public key
- The signature of a certification authority (e.g., Let's Encrypt, DigiCert)
- The expiration date
Your browser checks all this automatically. If something doesn't match → 🔴 "Your connection is not private".
What is Diffie-Hellman?
It's a mathematical method for two parties to agree on a common secret, even if someone is listening to all their messages.
Paint color analogy:
You: secretly choose BLUE 🔵
Bank: secretly chooses RED 🔴
Public base color: YELLOW 🟡
You: mix YELLOW + BLUE = GREEN 🟢 → you send GREEN
Bank: mixes YELLOW + RED = ORANGE 🟠 → it sends ORANGE
You: receive ORANGE + your secret BLUE = BROWN 🟤
Bank: receives GREEN + its secret RED = BROWN 🟤
✅ You have the same final color (BROWN)!
❌ The spy only sees GREEN and ORANGE... they cannot find BROWN!
In reality, these aren't colors but large mathematical numbers, but the principle is the same.
Concrete Example: Opening https://google.com
Here's what actually happens when you type https://google.com in your browser:
┌─────────────────────────────────────────────────────────────────────┐
│ YOUR PC (192.168.1.50) GOOGLE (142.250.80.46) │
│ │
│ ── STEP 1: DNS RESOLUTION ─────────────────────────────────── │
│ "What's the IP of google.com?" │
│ → DNS Response: 142.250.80.46 │
│ │
│ ── STEP 2: TCP HANDSHAKE ──────────────────────────────────── │
│ Packet 1: [SYN] 192.168.1.50:54321 → 142.250.80.46:443 │
│ Packet 2: [SYN,ACK] 142.250.80.46:443 → 192.168.1.50:54321 │
│ Packet 3: [ACK] 192.168.1.50:54321 → 142.250.80.46:443 │
│ ✅ TCP connection established on port 443 (HTTPS) │
│ │
│ ── STEP 3: TLS HANDSHAKE ──────────────────────────────────── │
│ Packet 4: ClientHello → TLS versions, proposed algorithms │
│ Packet 5: ServerHello ← chosen algorithm │
│ Packet 6: Certificate ← google.com certificate │
│ Packet 7: Key Exchange ↔ Diffie-Hellman exchange │
│ Packet 8: Finished ↔ verification on both sides │
│ 🔒 TLS tunnel established — everything is encrypted now │
│ │
│ ── STEP 4: ENCRYPTED DATA ──────────────────────────────────── │
│ Packet 9: [PSH,ACK] (encrypted) → GET / HTTP/1.1 │
│ (your request for the homepage) │
│ Packet 10: [ACK] ← acknowledgment │
│ Packet 11: [PSH,ACK] (encrypted) ← HTTP/1.1 200 OK + HTML page │
│ (Google's homepage) │
│ Packet 12: [ACK] → acknowledgment │
│ 📄 The Google page displays in your browser! │
│ │
│ ── STEP 5: CLOSURE ────────────────────────────────────────── │
│ Packet 13: [FIN,ACK] → "I'm done" │
│ Packet 14: [FIN,ACK] ← "Me too" │
│ Packet 15: [ACK] → "OK, goodbye" │
│ 🔌 Connection closed │
└─────────────────────────────────────────────────────────────────────┘
Port 443 vs Port 80
- Port 80 = HTTP (not encrypted) → no TLS handshake
- Port 443 = HTTPS (encrypted) → mandatory TLS handshake
That's why the https:// URL always uses port 443 by default.
What You See in Wireshark
HTTP Capture (port 80) – NOT encrypted
┌──────┬────────────────────┬────────────────────┬──────────┬──────────────────────┐
│ No │ Source │ Destination │ Protocol │ Info │
├──────┼────────────────────┼────────────────────┼──────────┼──────────────────────┤
│ 1 │ 192.168.1.50 │ 93.184.216.34 │ TCP │ SYN │
│ 2 │ 93.184.216.34 │ 192.168.1.50 │ TCP │ SYN, ACK │
│ 3 │ 192.168.1.50 │ 93.184.216.34 │ TCP │ ACK │
│ 4 │ 192.168.1.50 │ 93.184.216.34 │ HTTP │ GET / HTTP/1.1 ⚠️ │
│ 5 │ 93.184.216.34 │ 192.168.1.50 │ TCP │ ACK │
│ 6 │ 93.184.216.34 │ 192.168.1.50 │ HTTP │ 200 OK ⚠️ │
└──────┴────────────────────┴────────────────────┴──────────┴──────────────────────┘
⚠️ Everything is visible in clear text! The request, the response, the page content...
Anyone on the network can read this data!
HTTPS Capture (port 443) – Encrypted
┌──────┬────────────────────┬────────────────────┬──────────┬──────────────────────┐
│ No │ Source │ Destination │ Protocol │ Info │
├──────┼────────────────────┼────────────────────┼──────────┼──────────────────────┤
│ 1 │ 192.168.1.50 │ 142.250.80.46 │ TCP │ SYN │
│ 2 │ 142.250.80.46 │ 192.168.1.50 │ TCP │ SYN, ACK │
│ 3 │ 192.168.1.50 │ 142.250.80.46 │ TCP │ ACK │
│ 4 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Client Hello │
│ 5 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Server Hello │
│ 6 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Certificate │
│ 7 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Key Exchange │
│ 8 │ ... │ ... │ TLSv1.3 │ Finished │
│ 9 │ 192.168.1.50 │ 142.250.80.46 │ TLSv1.3 │ Application Data 🔒 │
│ 10 │ 142.250.80.46 │ 192.168.1.50 │ TLSv1.3 │ Application Data 🔒 │
└──────┴────────────────────┴────────────────────┴──────────┴──────────────────────┘
🔒 "Application Data" = encrypted data. We cannot read the content!
We only see that there is traffic, but not WHAT is being exchanged.
What an attacker can see in HTTPS
Even with HTTPS, an attacker on the network can see:
- The server's IP address (e.g., 142.250.80.46)
- The site's name (via the SNI field in ClientHello, e.g.,
google.com) - The amount of data exchanged
- The timing of the connection
But they cannot see:
- ❌ The full URL (e.g.,
/search?q=my+secret) - ❌ The page content
- ❌ Cookies, passwords, forms
- ❌ Data sent in both directions
Final Summary – The Complete Analogy
HTTP vs HTTPS in one image
┌─────────────────────────────────────────────────────────────────────┐
│ │
│ HTTP (port 80) HTTPS (port 443) │
│ │
│ 📞 TCP Handshake 📞 TCP Handshake │
│ (SYN → SYN,ACK → ACK) (SYN → SYN,ACK → ACK) │
│ │ │ │
│ │ 🔒 TLS Handshake │
│ │ (ClientHello → Certificate → Keys) │
│ │ │ │
│ ▼ ▼ │
│ 📦 Data IN CLEAR 📦 Encrypted Data │
│ (everyone can read) (no one can read) │
│ │ │ │
│ 👋 TCP Closure 👋 TCP Closure │
│ (FIN → ACK) (FIN → ACK) │
│ │
│ 🔴 Dangerous! 🟢 Secure! │
└─────────────────────────────────────────────────────────────────────┘
The TCP Flags Memo
┌──────────────────────────────────────────────────────────────────┐
│ TCP FLAGS MEMO │
│ │
│ SYN = 📞 "I want to open a connection" │
│ ACK = ✅ "Received!" │
│ PSH = 📦 "Here's data, process it right away" │
│ FIN = 👋 "I'm done, goodbye" │
│ RST = ❌ "Hung up forcefully!" │
│ │
│ SYN,ACK = 📞✅ "I accept your connection + received" │
│ PSH,ACK = 📦✅ "Here's data + I received yours" │
│ FIN,ACK = 👋✅ "I'm closing + I received your last messages" │
└──────────────────────────────────────────────────────────────────┘
The Summary in 5 Sentences
Summary
- TCP opens the connection with SYN / SYN-ACK / ACK (3-way handshake)
- TLS secures the connection with certificate + key exchange (TLS handshake)
- PSH,ACK sends the real data (HTTP requests, web pages, etc.)
- FIN,ACK properly closes the connection
- ACK accompanies almost everything: it's just an "acknowledged" to ensure nothing is lost
Bonus TP created on: February 2026