The TLS Handshake

What a capture can still see after everything is encrypted

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Follow the handshake flight and say what each message establishes
▸Read a certificate chain and explain what makes it trustworthy
▸State precisely what remains visible to an observer once encryption starts

Before this lesson — it builds directly on:

Sending anything over a network you do not control has three separate risks, and TLS addresses all three: Someone reads it. Solved by encryption — confidentiality. Someone changes it. Solved by integrity checks; a modified message is detected, not silently accepted. You are talking to the wrong party entirely. Solved by the certificate — authentication. The third is the one people skip, and it is the one that makes the other two matter. A perfectly encrypted, perfectly intact conversation with an impostor is a total failure. That is why a certificate warning is serious even though the connection is still encrypted.

✗ Common misunderstanding: The certificate is what encrypts the connection.

Why that's wrong: Encryption comes from the key agreement. The certificate's job is identity: proving the server is who the name says.

Correct model: Certificate = identity. Key agreement = confidentiality. A connection with a bad certificate is still encrypted — to a party you have not identified.

The packets prove it: In the hostname-mismatch trace the handshake proceeds normally and the client rejects it afterwards, on identity grounds alone.

✗ Common misunderstanding: With HTTPS, an observer learns nothing.

Why that's wrong: Only the application payload is encrypted. Addresses, ports, packet sizes, timing and the site name in SNI are all readable, because they must be for the packet to be delivered and the handshake to work.

Correct model: HTTPS hides WHAT you said. It does not hide who you talked to, when, or how much.

The packets prove it: Read the SNI in any TLS handshake in this module — the site name is in plain text, before any key exists.

Watch these fields in the lab: tcp.payload

Two separate ideas, often muddled. The sealed envelope is encryption. Nobody handling it can read the contents, and if they tamper with it you can tell. That comes from the keys the two sides agree on during the handshake. The signature on the door is the certificate. Before you post anything, you check the nameplate is genuine — vouched for by an authority you already trust, not just written by whoever is inside. Sealing an envelope and posting it through the wrong door protects nothing worth protecting. That is why the certificate check is not a formality. Where the analogy breaks: a real signature can be photographed and forged; a certificate signature is verified mathematically against a key, so copying it does not help.

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Which of TLS's three guarantees does a certificate provide?

Why can a network filter block specific HTTPS sites without decrypting anything?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.