Helpful first: Networks in one request: DNS, TCP, TLS, and HTTP
Key points
- TLS key derivation, server authentication, and handshake completion stay separate from human login and from permission.
- Contrast forward-secret ephemeral key agreement with sending a password on the wire or accepting a wrong-name certificate
Agreeing on a secret across a hostile room
Once TCP reaches ESTABLISHED, Meridian’s client and telemetry. have an open byte stream, but every router on the path can still read every packet. If the client simply generated an AES key and mailed it across the socket, any eavesdropper on the Wi-Fi would copy that key too.
TLS 1.3 solves this with two distinct cryptographic mechanisms working together: ephemeral Diffie-Hellman key agreement (typically ECDHE over X25519 or P-256) to derive a forward-secret session key without transmitting it, and an X.509 digital signature to bind that key exchange to the verified server name.
Public value stubs on the wire, shared session secret in memory
Watch how the figure separates what rides the network rail from what stays inside each endpoint’s memory. During the handshake, both sides generate temporary private numbers and send only their Public value stubs (ClientHello key_ and ServerHello key_) across the path. Using elliptic-curve math, each side combines its own private secret with the peer’s public stub to Derive the exact same Session secret in local memory.
Because the private inputs never leave their hosts, a passive observer who records all the Public value stubs cannot compute the Session secret. Furthermore, because those key shares are ephemeral (thrown away after the session ends), TLS 1.3 provides Perfect Forward Secrecy (PFS): even if an attacker steals the server’s long-term certificate private key next year, they cannot decrypt today’s recorded Application data.
At the same time, key math alone would let a person-in-the-middle negotiate a Shared secret with you while pretending to be Meridian. That is why the server also sends its certificate and signs the handshake transcript. The client checks Name bind: does a trusted Certificate Authority vouch for telemetry., and does the signature match? Compare the three modes in the figure: Shared secret (normal TLS 1.3 derivation and valid name bind), Password on wire (the broken anti-pattern of sending secrets without encryption), and Wrong-name cert (where key math succeeds, but the certificate belongs to another domain so the client aborts before sending Application data).
SESSION SECRET
Keys first. Then trust.
Follow a TLS 1.3 handshake: public shares, local keys, encrypted server proof, checks, and Finished.
TCP is ready. Neither endpoint has authenticated the server or enabled application data.
More about this step
Certificate-based TLS 1.3 with ephemeral ECDHE, no PSK, resumption, early data, HelloRetryRequest, ECH, or client certificate. This is a decoded teaching model, not live cryptography. Browser B7 represents the customer phone; TLS server is Chronos Hub and Observer is cafe Wi-Fi.
Chapter 1 of 8
Decoded TLS 1.3 teaching model, not live cryptography. Cafe Wi-Fi sees public Hellos and later ciphertext. This server waits for Client Finished; TLS also permits earlier server data. A protected channel does not identify the client human or grant application permission.
Read all chapters
Nothing plays on its own. Watch all runs one overview. Replay this step stops on the selected chapter; Pause and Resume keep your place. Scrub or choose a chapter to inspect. Opening detail, leaving the picture, or hiding the tab pauses playback. Reduced motion shows still chapters with no travel.
Matching name
- TCP is ready. Neither endpoint has authenticated the server or enabled application data.Certificate-based TLS 1.3 with ephemeral ECDHE, no PSK, resumption, early data, HelloRetryRequest, ECH, or client certificate. This is a decoded teaching model, not live cryptography. Browser B7 represents the customer phone; TLS server is Chronos Hub and Observer is cafe Wi-Fi.
- ClientHello delivers public share A to Chronos Hub. Private a stays at the browser.A summarizes the ephemeral public key, not a password. ClientHello also carries supported parameters. Receipt follows arrival; Cafe Wi-Fi can read this unencrypted Hello.
- ServerHello delivers public share B. Chronos Hub has derived its handshake keys locally.Chronos Hub uses private b, peer share A, and the Hello transcript. ServerHello carries the negotiated parameters and share B, not the certificate or the private keys.
- The browser derives handshake keys locally. The server name is still unchecked.Both endpoints derive the same ECDHE shared material. HKDF and the Hello transcript produce distinct client-to-server and server-to-client handshake traffic keys, not one universal key.
- Encrypted server messages arrive. The browser can decode the certificate; it has not accepted it.The protected flight contains EncryptedExtensions, Certificate, CertificateVerify, and server Finished. Its decoded labels are for the learner. A passive Cafe Wi-Fi observer sees ciphertext.
- The browser validates chain, time, target name, CertificateVerify, and server Finished.Assumed validation succeeds for the configured trust store, validity time, DNS-ID, CertificateVerify signature over the transcript, and Finished MAC. Keys alone were insufficient.
- The browser has sent encrypted Client Finished. Chronos Hub receives it, but has not verified it.Client Finished confirms transcript and keys. The browser may send application data after sending it. The outbound message is fully sent before this modeled flight; Chronos Hub waits to verify its receipt.
- Chronos Hub verifies Client Finished and accepts the channel. No human login or shipment permission is granted.The server now permits application data, using separately derived directional application traffic keys. The browser was already ready after sending Finished; it learns no server check result here.
Wrong-name cert
- TCP is ready. Neither endpoint has authenticated the server or enabled application data.Certificate-based TLS 1.3 with ephemeral ECDHE, no PSK, resumption, early data, HelloRetryRequest, ECH, or client certificate. This is a decoded teaching model, not live cryptography. Browser B7 represents the customer phone; TLS server is Chronos Hub and Observer is cafe Wi-Fi.
- ClientHello delivers public share A to Chronos Hub. Private a stays at the browser.A summarizes the ephemeral public key, not a password. ClientHello also carries supported parameters. Receipt follows arrival; Cafe Wi-Fi can read this unencrypted Hello.
- ServerHello delivers public share B. Chronos Hub has derived its handshake keys locally.Chronos Hub uses private b, peer share A, and the Hello transcript. ServerHello carries the negotiated parameters and share B, not the certificate or the private keys.
- The browser derives handshake keys locally. The server name is still unchecked.Both endpoints derive the same ECDHE shared material. HKDF and the Hello transcript produce distinct client-to-server and server-to-client handshake traffic keys, not one universal key.
- Encrypted server messages arrive. The browser can decode the certificate; it has not accepted it.The protected flight contains EncryptedExtensions, Certificate, CertificateVerify, and server Finished. Its decoded labels are for the learner. A passive Cafe Wi-Fi observer sees ciphertext.
- The trusted, in-date certificate names another service. The browser aborts before later proof checks.The chain and time checks pass. other.example.test does not match track.example.test. This client stops at name failure; later proof checks are not claimed to run. No bypass is offered.
- The browser sends an encrypted bad_certificate fatal alert. Chronos Hub receives the abort.This model uses bad_certificate for the name failure. The alert is protected with client handshake keys because Client Finished was not sent. Receipt is distinct from handling the abort.
- The connection closes. Earlier key derivation did not make the wrong server name acceptable.Derived-key labels record the earlier computation; they do not promise storage or reuse after abort. No protected HTTP request is sent. The model says nothing about an attack or a human identity.
Show as a table
TLS 1.3: public Hellos, local handshake keys, encrypted server proof, client validation, and Client Finished. A wrong-name certificate aborts despite earlier key derivation. Application keys are separate; TLS grants no human permission.
| Chapter / assumption | What the model establishes |
|---|---|
| Context | TCP is established. A fresh certificate-based TLS 1.3 ECDHE handshake begins. No PSK, resumption, 0-RTT, HelloRetryRequest, ECH, client certificate, packet loss, or active attacker is modeled. |
| Safe references | a, b, A, and B are symbolic references, not cryptographic test values. |
| ClientHello | The browser generates ephemeral private a and public share A. Only A and public negotiation fields are sent. Chronos Hub records A after arrival. |
| Observer | Cafe Wi-Fi is a passive observer without endpoint access. It reads public Hellos; later it sees ciphertext and traffic metadata. Observer labels describe visibility, not a separately timed capture. |
| ServerHello | Chronos Hub generates ephemeral private b and public share B. With A it computes ECDHE shared material and derives directional handshake keys from the Hello transcript. |
| ServerHello contents | B arrives in the unencrypted ServerHello with negotiated parameters. The certificate is not in this message. |
| Local keys | The browser combines private a with B, deriving the same shared material and directional handshake keys. The two directions have different keys. Keys alone do not establish the expected server identity. |
| Server proof | EncryptedExtensions, Certificate, CertificateVerify, and server Finished use server handshake traffic protection. The grouped flight preserves their order. The browser can decrypt them; decoding is not acceptance. |
| Client checks | The matching-name case assumes a trusted valid chain at the chosen time, appropriate algorithms and extensions, DNS-ID track.example.test, a valid CertificateVerify signature, and a valid server Finished MAC. |
| CertificateVerify | CertificateVerify proves control of the certificate signing key and binds the handshake transcript. That signing key is separate from ephemeral ECDHE private b. Finished confirms transcript and keys. |
| Wrong-name checks | Trust-chain and time checks still pass. The alternate certificate has DNS-ID other.example.test; it is not valid for the expected track.example.test. |
| Wrong-name abort | This client rejects the name and does not claim later CertificateVerify or Finished processing. It sends an encrypted bad_certificate fatal alert without Client Finished or application data. No bypass is offered. |
| Client reply | The browser fully sends Client Finished before the modeled flight. It may now send application data. Chronos Hub records receipt, then checks the Finished MAC. The wrong-name path sends a fatal alert instead. |
| Outcome | After successful Finished verification, this server permits application data. The server chooses to wait; this policy is not universal TLS behavior. No result message is sent back to the browser here. |
| Earlier server data | RFC 8446 also permits a server to send application data after its own first flight, before receiving Client Finished. The earlier-data option is outside this example. |
| Application keys | Application traffic keys are derived separately for each direction from the transcript through server Finished. The picture tracks permission to use the channel, not their exact derivation instant. |
| Secret lifetime | Local private/key labels record ownership or prior computation, not memory-retention guarantees. Implementations should erase obsolete secrets; the figure promises no storage or reuse after abort. |
| Permission limit | Certificate and Finished validation does not authenticate the client human, certify the business, or authorize reading shipment 8821. No HTTP exchange is shown. |
Scene checked 2026-09-30.
Check the picture
In a TLS 1.3 handshake, path-visible values and the derived session secret stay distinct. Which statement accurately describes the protocol guarantees?
Certificate name binding is not human identity or permission
Unless an organization explicitly configures mutual TLS (mTLS) with client certificates, a standard TLS handshake is one-way authentication: the client authenticates the server’s hostname (telemetry.), while the server knows nothing about which human or service opened the tunnel.
Even after the handshake completes and encrypted Application data flows, the server still has to authenticate the caller (via an OIDC session, WebAuthn assertion, or OAuth access token) and enforce authorization checks on every requested object.
| Mechanism | What It Proves | What Fails If Missing |
|---|---|---|
ECDHE Key Exchange (key_) | Both endpoints share a forward-secret symmetric key that never crossed the wire | Passive eavesdroppers or future key compromise could expose payload confidentiality |
X.509 Certificate + CertificateVerify | The endpoint terminating TLS controls the private key for telemetry. | Active on-path attacker can impersonate the server (Wrong- or untrusted CA) |
| Application AuthN & AuthZ (HTTP layer) | Which user or workload is calling and which resources they may read or modify | Any caller over a valid HTTPS tunnel can read or overwrite sensitive records |
Where TLS sits in the stack
TLS relies on TCP below it to deliver handshake records in order, and HTTP relies on TLS below it to protect verbs, headers, and payloads in transit. Keep each layer’s boundary crisp: TCP proves two-way packet reachability, TLS proves server hostname authenticity and encrypts the pipe with forward secrecy, and the application enforces human login and resource authorization.
CHECK YOUR JUDGMENT