✳ Field lesson F3b / 8 min

Public values travel. The session secret does not.

After TCP is ESTABLISHED, both ends exchange ephemeral public values. Cafe Wi-Fi may see those. Both ends derive the shared session secret locally. A matching certificate name is not human permission.

foundationsnetworktlsencryptionsession-secret

What you’ll be able to do

  • Name what cafe Wi-Fi may observe during a modern TLS handshake (ephemeral public values) versus where the shared session secret appears (derived locally at both ends).
  • Explain that the session secret is not sent as a shared password on the wire.
  • Separate certificate name-bind for a typed name from human authentication and authorization to open a shipment.

Public values travel. The session secret does not.

After TCP reaches ESTABLISHED, TrackPort and the customer’s phone still need a protected application conversation. In a modern TLS 1.3 handshake they exchange ephemeral public values. Cafe Wi-Fi on the path may observe those public stubs. Both ends then derive a shared session secret locally. That secret is used to protect the HTTP bytes. It is not sent as a password on the wire.

A certificate binds a public key to a name such as track.riverstone.example. A matching name-bind is a check on the owner of that name for this connection. It is not proof of which human sits at the phone, and it is not authorization to open shipment 8821. A padlock and a valid certificate for a typed name still leave authentication and authorization to the application. More on that edge: the TLS glossary and the encryption-not-the-right-owner misconception.

You do not need the full TLS 1.3 transcript. Watch which values travel on the cafe-visible rail, where the session-secret wells fill, and what fails when the certificate name does not match the name the customer typed. Reachability stays with the TCP lesson. Name, DNS, and cookie faults stay with the Networks relay-race figure.

SESSION SECRET

The secret stays at the ends

Watch public values travel and session secrets form locally.

Choose a path
RIVERSTONE / TRACKPORTPublic travels.Secret stays.Cafe Wi-Fi! Secret exposedClientPhonePrivate stays hereSession secretReadyServerTrackPortPrivate stays hereSession secretReadyName bindWaitTyped TrackPort nametrack.riverstone.exampleCertificatetrack.riverstone.examplePublic travels. Secret stays.Name bind is not human permission.

Client phone and TrackPort Server prepare a protected conversation.

Chapter 1 of 5

Read all chapters

Plays once when the picture comes into view, then stops. Play resumes; Replay starts over. Scrub or choose a chapter to pause and inspect. Leaving the picture or hiding the tab pauses playback. Reduced motion shows still chapters with no travel.

Shared secret

  1. Client phone and TrackPort Server prepare a protected conversation.Riverstone uses TrackPort. Cafe Wi-Fi can observe the rail. Both session-secret wells are empty. No identity or permission is granted.
  2. An ephemeral public value travels from Client to Server. Cafe Wi-Fi may see it.The public stub crosses the rail. Private material stays inside each house. The session-secret wells remain empty.
  3. Server sends its public value back. The certificate matches the typed TrackPort name.Name bind holds for track.riverstone.example. Private material stays inside Server. No session secret travels.
  4. Both ends derive the same session secret locally. Nothing secret crosses the rail.The twin wells fill inside their houses. The public stubs park. The session secret protects HTTP bytes.
  5. Public values travel. The session secret does not.A certificate binds a public key to a name. It does not prove human identity, a trustworthy business, or permission to open shipment 8821.

Password on wire

  1. Client phone and TrackPort Server prepare a protected conversation.Riverstone uses TrackPort. Cafe Wi-Fi can observe the rail. Both session-secret wells are empty. No identity or permission is granted.
  2. This anti-path sends a password on the cafe rail. It is not how the shared TLS secret is derived.A warm, notched password stub travels Client to Server. Cafe Wi-Fi sees the secret. Both local wells stay empty.
  3. This anti-path sends a password on the cafe rail. It is not how the shared TLS secret is derived.A warm, notched password stub travels Client to Server. Cafe Wi-Fi sees the secret. Both local wells stay empty.

Wrong-name cert

  1. Client phone and TrackPort Server prepare a protected conversation.Riverstone uses TrackPort. Cafe Wi-Fi can observe the rail. Both session-secret wells are empty. No identity or permission is granted.
  2. An ephemeral public value travels from Client to Server. Cafe Wi-Fi may see it.The public stub crosses the rail. Private material stays inside each house. The session-secret wells remain empty.
  3. Wrong name. Client refuses this connection as TrackPort.Typed track.riverstone.example differs from certificate track.riverst0ne.example. The Server name-bind seal cracks. Trust does not settle.
  4. Wrong name. Client refuses this connection as TrackPort.Typed track.riverstone.example differs from certificate track.riverst0ne.example. The Server name-bind seal cracks. Trust does not settle.
Read this as a table

Ephemeral public values may cross cafe Wi-Fi. Both ends derive a shared session secret locally. Password on wire exposes a secret. Wrong-name cert refuses TrackPort trust. A name bind is not human authorization.

The secret stays at the ends in text
Path / chapterWhat changes
PlaceClient phone and TrackPort Server prepare a protected conversation.
Public outAn ephemeral public value travels from Client to Server. Cafe Wi-Fi may see it.
Public backServer sends its public value back. The certificate matches the typed TrackPort name.
DeriveBoth ends derive the same session secret locally. Nothing secret crosses the rail.
SettlePublic values travel. The session secret does not.
Password on wireA warm, notched password stub travels Client to Server. Cafe Wi-Fi sees the secret. Both local wells stay empty.
Wrong-name certTyped track.riverstone.example differs from certificate track.riverst0ne.example. The Server name-bind seal cracks. Trust does not settle.

Scene checked 2026-09-28.

Use this picture in the check below

CHECK THE PICTURE

Cafe Wi-Fi watched a customer phone complete a TLS session to TrackPort for track.riverstone.example. What rode the cafe path, and where did the shared session secret appear?

Name-bind is not human permission

Certificate name-bind answers whether this connection’s certificate matches the name the customer typed. On the figure, wrong-name refuses TrackPort trust when the cert names a lookalike. That is the check working.

Name-bind does not authenticate which human holds the phone. It does not authorize shipment 8821. Those checks stay with the application after the TLS session exists.

Reachability and what comes next

On the Riverstone cast, the customer’s phone still needs TCP ESTABLISHED before any of this matters. That road lives on the TCP elective: Three packets. Then ESTABLISHED. Name, DNS, cookie, and wrong-host faults live on the Networks lesson’s relay-race figure.

Come back here when someone treats a padlock as proof that cafe Wi-Fi already shared a password, or that encryption proved the right human and the right shipment. Public values may travel. The session secret does not. Permission stays with the application.

CHECK YOUR JUDGMENT

A phone protects a TrackPort conversation. Priya’s customer is on cafe Wi-Fi. The phone already has TCP ESTABLISHED to TrackPort on 443. Before GET /shipments/8821 is safe to send, both ends still need a TLS session. Public values may cross the cafe rail, the shared session secret must form locally, and the certificate must match track.riverstone.example. This lesson stops when public values, the local session secret, and name-bind are distinct. What should Priya keep distinct?

Put your learning to work ↗

Find your next idea.

Tip: press / to open search. Escape closes this window.