HTTPS
HTTP over TLS · Application layer
HTTPS is the whole stack working together. Following one request from a name to an encrypted response ties together every protocol in this curriculum, and shows exactly where the boundary between visible and encrypted falls.
Understand these first
- Why does this protocol exist?
- It is not a separate protocol. It is the name for HTTP carried inside TLS carried inside TCP — the arrangement that made the web usable for anything private.
- Which problem does it solve?
- Fetch a web resource with confidentiality, integrity and server authentication, using pieces that already existed rather than a new protocol.
- Who participates?
- The same client and server as HTTP, plus TLS's certificate authorities, plus DNS beforehand.
- Which layer uses it?
- A stack rather than a layer: HTTP/1.1 or HTTP/2 over TLS over TCP, on port 443. HTTP/3 is a different stack — HTTP/3 over QUIC over UDP.
- What does it depend on?
- DNS, TCP, TLS — and therefore, underneath those, IP and ARP.
- What depends on it?
- Nearly all web applications and the browser security model built on top of them.
- What state does each participant maintain?
- The union of the layers: TCP's connection state, TLS's keys and session, and whatever the application keeps in cookies. Nothing extra of its own.
- Which fields matter?
- TCP port 443 — The convention that says to expect TLS. Only a convention — nothing enforces it.
- TLS SNI — The hostname in the clear, before any encryption. Usually the only readable evidence of which site is being visited.
- Certificate subject / SAN — What the client validates the hostname against. The single most common HTTPS failure lives here.
- encrypted application data — The HTTP request and response. Present in the capture, unreadable, and the sizes and timing still leak information.
- What does normal behaviour look like?
- DNS lookup, TCP handshake, TLS handshake, then encrypted records carrying HTTP. Four distinct phases in one capture, each depending on the last succeeding.
- What does failure look like?
- Whichever layer failed, failing in its own way — and the browser reports them all as one vague message. DNS failure, TCP timeout, TLS certificate rejection and HTTP 500 are four completely different diagnoses.
- How can I prove the diagnosis from packets?
- Work up the stack in order. Did DNS answer? Did the handshake complete? Did TLS finish or alert? Only then look at HTTP. The first layer that failed is the answer, and looking at them out of order wastes most of the time people spend on this.
- How does it interact with the rest of the stack?
- It is the whole curriculum in one trace, which is why it is the last module: every layer beneath it must already make sense.
Guided course — 2 lessons
Read in order. Every lesson pauses the capture on the packets it is talking about, and every one reads at three levels — so the time below is an estimate from the number of steps, not a measurement of anybody.
- 1HTTPS-01HTTPS: Every Layer at OnceNot a protocol — a stack≈10 min · 8 steps · 4 questions · guidedNot started
- 2HTTPS-02Which Layer FailedOne page load, six places it can go wrong, and how to tell them apart≈10 min · 7 steps · 3 questions · guided · diagnosis lab · after https-the-whole-stackNot started
Troubleshooting labs — 1
A symptom, a capture, and no answer given. Each one is a lesson from the course above, listed again here because the diagnosis is worth coming back for.
Reference material
The terms this module introduces, and the specifications behind them. Both lists come from the lessons themselves rather than from a list kept beside them.
That you can describe the stack precisely, including where it stops being TCP.