TLS
Transport Layer Security · Between transport and application
TLS wraps an ordinary TCP connection so that an observer can see that traffic is flowing but not what it says, and so the client can verify it is really talking to the server it asked for. The start of the handshake — ClientHello and ServerHello — is still readable in a capture; in TLS 1.3 everything after ServerHello, including the certificate, is encrypted. What no encryption hides is the shape of the traffic: timing, sizes, direction, endpoints and how long the connection lasts.
Understand these first
- Why does this protocol exist?
- TCP protects against accidents, not adversaries. Anything on the path can read and modify a plain TCP stream, and nothing in TCP would notice.
- Which problem does it solve?
- Give a TCP stream three things it does not have: confidentiality, integrity, and proof of who the other end is.
- Who participates?
- A client and a server, plus certificate authorities whose signatures the client already trusts before the connection begins.
- Which layer uses it?
- Between transport and application. It takes a TCP stream and offers an identical-looking stream that happens to be encrypted.
- What does it depend on?
- TCP for a reliable ordered stream, and DNS for the name it will validate the certificate against.
- What depends on it?
- HTTPS, secure mail, and most modern application protocols.
- What state does each participant maintain?
- A great deal after the handshake: negotiated cipher suite, session keys in each direction, sequence numbers for replay protection, and the peer's verified identity. Session tickets let some of it be resumed later.
- Which fields matter?
- record header — Content type, version and length — the only part of every record that stays in the clear.
- ClientHello: SNI — The hostname, sent before encryption begins, because the server needs it to pick a certificate. Visible by default.
- ClientHello: cipher suites — What the client will accept. The server picks one, and that choice is the whole negotiation.
- Certificate — The server's identity and chain. In TLS 1.2 this is visible; in TLS 1.3 it is encrypted.
- Alert — How TLS reports failure. bad_certificate and handshake_failure are the ones you will meet.
- What does normal behaviour look like?
- ClientHello, ServerHello, then key agreement and certificate exchange, then Finished in both directions, then application data as encrypted records indistinguishable from each other.
- What does failure look like?
- An alert during the handshake, and the connection closing before any application data. Hostname mismatch, expired certificate and unknown issuer all appear here — and all of them are the client refusing, not the server failing.
- How can I prove the diagnosis from packets?
- Read the ClientHello's SNI and compare it with the subject and SAN in the certificate that came back. A mismatch is visible directly, and the alert that follows names the reason.
- How does it interact with the rest of the stack?
- TLS sits on TCP and carries HTTP. It moves the visibility boundary: below it everything is readable, above it nothing is. What stays visible even after encryption is the timing, sizes, direction and endpoints — which is enough to do real traffic analysis on.
The certificates and keys in this app's captures are structurally real but cryptographically illustrative — the bytes say so explicitly. Nothing here performs production cryptographic verification.
Guided course — 3 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.
- 1TLS-01The TLS HandshakeWhat a capture can still see after everything is encrypted≈10 min · 8 steps · 4 questions · guidedNot started
- 2TLS-02Troubleshooting: Certificate ErrorsThree failures that look identical to a user and are not≈10 min · 6 steps · 3 questions · guided · diagnosis lab · after tls-handshakeNot started
- 3TLS-03What the Handshake Actually AgreesVersions, cipher suites, ALPN — and what happens when there is no overlap≈10 min · 7 steps · 3 questions · guided · diagnosis lab · after tls-handshake, tls-when-validation-failsNot started
Troubleshooting labs — 2
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 say exactly what a capture of a TLS connection still reveals, and what a certificate does and does not prove.
Where TLS sits in a real request
These captures run TLS as one stage of a longer chain, and hand its result to whatever comes next.
The same four stages, plus one: before any request is sent, the server has to prove it is the server. Note what a capture can still read after encryption starts — and what it cannot.
A routed enterprise application, end to endThe office journeys stop at the gateway. This one starts before it: two routing protocols fill one routing table, then ARP and DNS do their usual jobs, then an application opens a connection across the result. Nothing in the application's packets refers to a routing protocol — and that is what the routing protocols are for.
Control plane and data planeTwo captures of one network. In the first, the routers talk only to each other and no user traffic exists at all. In the second, user traffic crosses the network — while the routing protocols carry on saying hello in the background, because they never stop. Not one of their packets carries a byte of anybody's data. OSPF and BGP create forwarding information; the routing table selects a path; IP forwards packets; TCP, TLS and HTTP carry the application. Each of those depends on the one before it having already finished.
Diagnosis: the browser warns before showing anythingThe connection opens fine, bytes flow both ways, and then the client hangs up on purpose. Something in what the server sent was unacceptable.