HTTPS: Every Layer at Once

Not a protocol — a stack

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

▸Name each layer of an HTTPS packet and what it contributes
▸Say where the boundary between visible and encrypted falls
▸Attribute a failure to the right layer from the capture alone

Before this lesson — it builds directly on:

HTTPS is not a protocol anyone designed. It is five existing protocols used together, each solving one problem and trusting the others to solve theirs. That could have gone differently. Someone could have built one enormous secure-web protocol handling addressing, delivery, encryption and requests all at once. It would have worked — and then IPv6 would have required rewriting all of it, and TLS 1.3 would have required rewriting all of it again. Instead each layer can change independently. HTTP moved from 1.1 to 2 to 3 without IP noticing. TLS went from 1.2 to 1.3 without HTTP noticing. The cost is latency: each layer needs its own handshake, and they happen in sequence.

✗ Common misunderstanding: HTTPS is a different protocol from HTTP.

Why that's wrong: It is the same HTTP, placed inside TLS records. The request line, the headers and the body are byte-for-byte what they would have been unencrypted.

Correct model: HTTPS = HTTP inside TLS inside TCP. Three protocols, not one new one.

The packets prove it: The full-flow trace shows an ordinary TCP handshake, then TLS, then the same HTTP request you read in the clear in the HTTP module — just wrapped.

✗ 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.destPort

"HTTPS" names an arrangement, not a protocol, so it is worth being exact about which arrangement. What you will see in this module is HTTP/1.1 or HTTP/2, inside TLS, over TCP, over IP, over a link layer. Five layers, each with its own header, in that order. HTTP/3 is also HTTPS to a user — the padlock looks identical — but it is a different stack. It runs over QUIC, which runs over UDP. There is no TCP handshake in the capture and no separate TLS record layer, because QUIC does both jobs itself.

The stack this module shows: HTTP/1.1 or HTTP/2 → TLS → TCP → IP → link layer. Port 443.
The HTTP/3 stack: HTTP/3 → QUIC → UDP → IP → link layer. Also port 443, also called HTTPS, and not the same thing.
Port 443: A convention, not a guarantee. It says 'expect encrypted web traffic', not which transport or which HTTP version.

Watch these fields in the lab: tcp.destPort

✓ 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.

What does layering actually buy, given it costs an extra round trip?

A site fails to load. The capture shows a completed TCP handshake, a completed TLS handshake, and then nothing. Where do you look?

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.