HTTPS Explorer
How does the padlock keep what you send private?
10 min
Words you’ll meet:
Loading the simulation…
How does the padlock keep what you send private?
Loading the simulation…
A full 1-RTT handshake to a site the client has never spoken to: key shares in the first message, the certificate already encrypted in the second, and an HTTP exchange nobody on the path can read.
What the two endpoints hold: the actual request and response.
7 steps. Pause, step back or replay any of them.
Nothing selected
Click anything on the map (a device, a cable, or a moving message) to see what it is.
Flight 1Client opening: capabilities, the SNI hostname, and a guessed key share.
Flight 2The server answers with everything at once -- and everything after ServerHello is already encrypted.
Encryption starts here— everything below this line is protected
Flight 3The client verifies the chain and finishes. It can attach its request to this same flight.
Flight 4Post-handshake: a ticket for next time.
Only two messages are ever in the clearRFC 8446 § 2
ClientHello and ServerHello. Everything from EncryptedExtensions onward -- including the certificate that identifies the server -- travels under handshake keys. In TLS 1.2 the certificate is broadcast in plaintext to anyone on the path, so an observer learns who you are talking to from the certificate itself. Here, they get the SNI hostname from the ClientHello and nothing more.
The ChangeCipherSpec records mean nothingRFC 8446 § D.4
TLS 1.3 has no ChangeCipherSpec; keys change when the key schedule says they do. These records exist only because middleboxes deployed in the TLS 1.2 era would drop a handshake that did not contain them, having been written to expect a specific message sequence. RFC 8446 s D.4 calls this "compatibility mode": a receiver must ignore them entirely. They are a monument to why protocol ossification is a real problem.
You are one of the two endpoints. You hold the traffic keys, so you have the records and their contents. Switch to the observer view to see the same connection from the path.
TLS protects the payload of a connection. It cannot hide the connection. Everything in this box is readable by every machine on the path, in both views, whatever version was negotiated.
GET /account/orders HTTP/1.1 Host: www.example.com User-Agent: InternetVisualizer/1.0 (simulated) Accept: text/html,application/xhtml+xml Accept-Encoding: gzip, br Cookie: session=8f2c19ab4d7e0553
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 122 Cache-Control: private, no-store Strict-Transport-Security: max-age=63072000; includeSubDomains <!doctype html> <title>Your orders</title> <h1>Your orders</h1> <p>Three items, and nobody on the path can read this.</p>
203.0.113.11
In the IP header, outside TLS entirely. TLS protects the payload of a connection; it cannot hide who the connection is to. Reverse-resolving this address is often enough to identify the site on its own.
www.example.com
Sent in the clear in the ClientHello, because the server needs it to choose which certificate to present -- before any keys exist. This is the single largest thing HTTPS does not hide, and the reason SNI-based filtering works. Encrypted Client Hello (ECH) closes it, but is not yet widely deployed.
14 records
When each record was sent, and the gaps between them. Enough on its own to distinguish a page load from a video stream from an idle connection, and enough for website fingerprinting against a known set of candidate pages.
5167 bytes on the wire
Record lengths are in the cleartext header and cannot be hidden, only obscured. Padding (RFC 8446 s 5.4) exists precisely for this and is almost never used, because it costs real bandwidth to defeat an attack most operators do not model.
TLS_AES_128_GCM_SHA256
Both Hello messages are in the clear, so the suite, the supported_versions choice, and both key shares are all readable. None of that helps decrypt anything -- but it does fingerprint the client, and a ClientHello is distinctive enough to identify the browser and often its version.
inside EncryptedExtensions
TLS 1.3 moved ALPN into EncryptedExtensions, under handshake keys, so the observer cannot see which application protocol was chosen. In TLS 1.2 it is in the cleartext ServerHello.
TLS 1.3 sends Certificate under handshake keys, one flight after ServerHello. An observer sees a record of some length and nothing more.
TLS 1.3 encrypts the real content type as TLSInnerPlaintext.type and stamps every protected record application_data(23). A Finished, an alert, and a POST body are indistinguishable (RFC 8446 s 5.2).
All of it is inside the application-data records. This is what HTTPS actually protects, and it is the part people worry about least.
A padlock is a claim that the payload is confidential and authentic between you and the name on the certificate. It is not a claim of anonymity: the address, the hostname, the timing and the sizes all survive it, and website fingerprinting works on exactly those.
Not real cryptography. Every key, secret, and signature shown here is a placeholder derived from a label string -- the shape of the derivation is accurate, the values are not, and nothing on this page encrypts anything.
The observer stops here— it holds both public shares and neither private value, and there is no known way to get from one to the other.
A 5-bit group, breakable by trying all 23 values by hand. It is here so the arithmetic is checkable, not because it protects anything -- a real connection uses X25519 with 256-bit exponents.
What the observer holds after the real exchange
Deriving the shared secret from the two public shares is the Diffie-Hellman problem. There is no known way to do it for X25519 in less than astronomically long -- and, crucially, no amount of *recording* helps, because the private values were never transmitted and are discarded when the connection ends.
The client asked for www.example.com and judged the chain as of 2026-03-01 against the simulated system trust store (1 root) (1 root).
The root above came from your trust store, not from the wire. A server may send its root and many do, but the client ignores that copy — otherwise anyone could append a self-signed root and vouch for themselves.
TLS_AES_128_GCM_SHA256 · 0x13,0x01
TLS 1.3 spells out 2 of the four decisions in the name. Key exchange and authentication moved into extensions, so the name now says only how records are protected and which hash the key schedule runs on. That is why TLS 1.3 has five suites and TLS 1.2 has several hundred.
The default nearly everywhere, and the one suite RFC 8446 s 9.1 requires an implementation to support.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is the TLS 1.2 suite this run is compared against — 4 components named, and forward secrecy either way.
TLS 1.2 waits 40 ms longer before the request can leave — one extra round trip, on every new connection, to every origin. It also starts encrypting a full round trip later, which is why its certificate is above the dashed line and TLS 1.3’s is below it. Both come from the same change: TLS 1.3 makes the client guess the group and send its key_share in the very first message, so the server can derive handshake keys the moment it has read the ClientHello.
| Aspect | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Round trips before application dataRFC 8446 § 2 | 2 (1 when resuming) | 1 (0 when resuming with early data) |
| Where encryption beginsRFC 8446 § 2 | After ChangeCipherSpec, a full round trip in | Immediately after ServerHello |
| Server certificateRFC 8446 § 4.4.2 | Plaintext, readable by anyone on the path | Encrypted under handshake keys |
| Key exchangeRFC 8446 § 1.2 | ECDHE, DHE, or static RSA -- configurable, and often misconfigured | (EC)DHE only; forward secrecy is not optional |
| Cipher suite nameRFC 8446 § B.4 | Four components; hundreds of registered suites | Two components; five suites total |
| Record content typeRFC 8446 § 5.2 | Honest in the header, so an observer can follow the conversation structure | Encrypted inside; every protected record claims application_data(23) |
| ChangeCipherSpecRFC 8446 § D.4 | A real message that switches the record layer | Removed; sent only as a hollow record to placate middleboxes |
| Key derivationRFC 8446 § 7.1 | A custom PRF; master secret not bound to the transcript without RFC 7627 | HKDF throughout; every secret bound to a transcript by construction |
| Record protectionRFC 8446 § 1.2 | AEAD or CBC-with-HMAC (MAC-then-encrypt), plus optional compression | AEAD only; CBC and compression removed |
| RenegotiationRFC 8446 § 1.2 | Supported, and the source of a decade of vulnerabilities | Removed; KeyUpdate and post-handshake authentication replace it |
| Replay riskRFC 8446 § 8 | None -- there is no 0-RTT mode | 0-RTT early data is replayable and needs server-side anti-replay |
The shaded row is the one where TLS 1.3 is not simply better. 0-RTT early data buys a round trip by sending the request under a key derived from a ticket, and a key derived from a ticket cannot be fresh — so a recorded 0-RTT flight can be replayed. It is safe only for requests that are safe to run twice.
Most of what happened between the two versions is removal: renegotiation, compression, static RSA key exchange, custom Diffie–Hellman groups, CBC, and every hash weaker than SHA-256 are all gone. Static RSA is the one worth naming — the client encrypted the premaster secret to the server’s long-term certificate key, so one leaked key decrypts every session ever recorded. That is what forward secrecy means, and TLS 1.3 made it non-optional by deleting the alternative.