A kiosk's TLS handshake to the shore-side booking service ends at an onboard gateway — which peer has the kiosk authenticated?

seniormust knowfreq 62%

answer

One peer, not a path
Who completed the handshake?
Proof of key possession, per name
CertificateVerify signs the transcript
Nothing proved beyond that peer

basics

~20 s

Only the peer that completed the handshake: the onboard gateway, which sent Certificate and signed CertificateVerify for that host name. The shore-side booking service sent nothing the kiosk verified, so nothing was proved about it.

solid answer

~50 s

A TLS handshake has two parties and authenticates one of them. In TLS 1.3 the server proves itself with Certificate, a CertificateVerify signature over the handshake transcript, and Finished; the peer that produced those three is the peer the client authenticated. If the onboard gateway holds a private key for the booking host's name and a chain the kiosk trusts, the kiosk's checks succeed — against the gateway. Whether a further connection is made to the shore-side service, whether it is authenticated, and who answers it are outside the exchange the kiosk took part in. And the kiosk cannot distinguish the two cases from the handshake: a correctly presented leaf looks the same whether the origin or an authorised edge holds the key. The guarantee is "this peer holds the key for this name", not "this response came from the origin".

A TLS handshake has two parties and authenticates one of them. In TLS 1.3 the server proves itself with `Certificate`, a `CertificateVerify` signature over the handshake transcript, and `Finished`; the peer that produced those three is the peer the client authenticated. If the onboard gateway holds a private key for the booking host's name and a chain the kiosk trusts, the kiosk's checks succeed — against the gateway. Whether a further connection is made to the shore-side service, whether it is authenticated, and who answers it are outside the exchange the kiosk took part in. And the kiosk cannot distinguish the two cases from the handshake: a correctly presented leaf looks the same whether the origin or an authorised edge holds the key. The guarantee is "this peer holds the key for this name", not "this response came from the origin".

code

pseudocode · 11 lines

pseudocode

on handshake complete with peer P:
    verified_name  = name checked in the leaf P sent in Certificate
    key_possession = signature in CertificateVerify over the transcript
    transcript_ok  = MAC in Finished

    conclude: P holds the private key for verified_name
    conclude: records on this connection are protected to P

    unknown: whether P is the origin or an intermediary
    unknown: how many hops sit behind P
    unknown: what authenticates or protects anything past P

go deeper

for a junior

Recall that a certificate binds a key to a name, and that the peer answering you is the one that proved it holds that key. Beyond that peer, the handshake says nothing.

for a middle

Explain the mechanics: Certificate carries the leaf, CertificateVerify signs the transcript, Finished binds the negotiation, and that trio authenticates exactly one peer under one name.

for a senior

Show you reason about reach: separate what the client has evidence for from what it merely assumes, and say how you would establish the rest from deployment knowledge instead of the protocol.

for a principal

Frame it as where the authenticated boundary should sit for a fleet of devices, and what evidence you can produce that everything past that boundary is accounted for by something other than this handshake.

What the handshake proves

A TLS handshake has exactly two parties. Everything it establishes is a statement about those two, and no message in the protocol carries a claim about anyone standing behind either of them.

In TLS 1.3 the server's half of that proof is three messages:

Certificate — the end-entity leaf the server wants to be judged by, plus whatever intermediates it chooses to put in the same certificate_list.
CertificateVerify — a signature, made with the private key belonging to that leaf, over the handshake transcript so far. This is the step that turns "here is a certificate" into "I hold its key".
Finished — a MAC over the transcript under the derived handshake keys, binding the negotiation together so a tampered flight cannot be completed.

A client that accepts all three has established one fact: the peer it is talking to controls the private key for a certificate that names the host it asked for, and that certificate chains to an anchor the client already trusts. Every mistake in this area comes from adding words to that sentence.

Where the proof stops

When the handshake ends at an onboard gateway rather than at the shore-side booking service, the gateway is the peer. It sent the Certificate. It produced the CertificateVerify signature. The kiosk authenticated the gateway, under the booking host's name. The shore-side service contributed nothing: it sent no message the kiosk saw and signed nothing the kiosk verified.

So after a completely successful handshake:

The kiosk has evidence for	The kiosk has no evidence for
The peer holds a key for the requested name	That the peer is the origin rather than an intermediary
The chain reaches an anchor it trusts	That anything behind the peer was authenticated at all
The transcript was not tampered with	That a further hop exists, or how many there are
Records after `Finished` are protected to that peer	What handles or protects the request past that peer

The last row is the one people state backwards. Record protection is a property of this connection between these two peers; the client has no message that would tell it the property extends further, because the protocol does not make that claim.

Why the kiosk cannot see the difference

There is no "I am an intermediary" flag. A certificate binds a key to a name — not to a machine, a company or a position in a network. An edge that legitimately holds a key for the booking host's name produces exactly the messages the origin would produce, and the client's validation succeeds in exactly the same way. Success is what hides the hop.

The handshake alone carries no statement about reach, but one in-band hint survives: the issuer of the leaf that was served. An operator who knows which authority normally signs for that host can notice when a different one did. That is knowledge brought to the handshake from outside it, not something the handshake asserts.

Common ways the conclusion gets stated backwards:

"The certificate proves the answer came from the origin." It proves who signed the transcript on this connection.
"TLS is end-to-end, so nothing can complete the handshake in the middle." Anything holding a key for the name completes it normally.
"A trusted chain means the whole path is authenticated." A chain is about one leaf and one anchor, not a sequence of hops.

The version delta

The conclusion — one peer, one name — holds in every version; only the message carrying the proof changes.

TLS 1.3: the server always sends CertificateVerify, because the ephemeral exchange is mandatory and static key transport was removed.
TLS 1.2: with an ephemeral exchange the server signed its parameters in server_key_exchange (12); with the static RSA key transport that 1.3 removed, it proved possession by being able to decrypt the client's client_key_exchange(16). In 1.2, CertificateVerify is the client's message, sent in answer to a CertificateRequest.

Using the conclusion

Name the authenticated boundary out loud when you describe a deployment: "the kiosk authenticates the onboard gateway" is a different sentence from "the kiosk authenticates the booking service", and only one of them is what the protocol did.
Treat every hop past that boundary as unauthenticated until something other than this handshake authenticates it; the kiosk has no way to inherit a guarantee it never received.
Read the issuer, not only the name, when you inspect what a client was served — the name will match by construction whenever the handshake succeeded at all.

## What the handshake proves A TLS handshake has exactly two parties. Everything it establishes is a statement about **those two**, and no message in the protocol carries a claim about anyone standing behind either of them. In TLS 1.3 the server's half of that proof is three messages: - **`Certificate`** — the end-entity leaf the server wants to be judged by, plus whatever intermediates it chooses to put in the same `certificate_list`. - **`CertificateVerify`** — a signature, made with the private key belonging to that leaf, over the handshake transcript so far. This is the step that turns "here is a certificate" into "I hold its key". - **`Finished`** — a MAC over the transcript under the derived handshake keys, binding the negotiation together so a tampered flight cannot be completed. A client that accepts all three has established one fact: **the peer it is talking to controls the private key for a certificate that names the host it asked for, and that certificate chains to an anchor the client already trusts.** Every mistake in this area comes from adding words to that sentence. ## Where the proof stops When the handshake ends at an onboard gateway rather than at the shore-side booking service, the gateway *is* the peer. It sent the `Certificate`. It produced the `CertificateVerify` signature. The kiosk authenticated the gateway, under the booking host's name. The shore-side service contributed nothing: it sent no message the kiosk saw and signed nothing the kiosk verified. So after a completely successful handshake: | The kiosk has evidence for | The kiosk has no evidence for | |---|---| | The peer holds a key for the requested name | That the peer is the origin rather than an intermediary | | The chain reaches an anchor it trusts | That anything behind the peer was authenticated at all | | The transcript was not tampered with | That a further hop exists, or how many there are | | Records after `Finished` are protected to that peer | What handles or protects the request past that peer | The last row is the one people state backwards. Record protection is a property of *this connection between these two peers*; the client has no message that would tell it the property extends further, because the protocol does not make that claim. ## Why the kiosk cannot see the difference There is no "I am an intermediary" flag. A certificate binds a key to a **name** — not to a machine, a company or a position in a network. An edge that legitimately holds a key for the booking host's name produces exactly the messages the origin would produce, and the client's validation succeeds in exactly the same way. Success is what hides the hop. The handshake alone carries no statement about reach, but one in-band hint survives: the **issuer** of the leaf that was served. An operator who knows which authority normally signs for that host can notice when a different one did. That is knowledge brought to the handshake from outside it, not something the handshake asserts. Common ways the conclusion gets stated backwards: 1. "The certificate proves the answer came from the origin." It proves who signed the transcript on this connection. 2. "TLS is end-to-end, so nothing can complete the handshake in the middle." Anything holding a key for the name completes it normally. 3. "A trusted chain means the whole path is authenticated." A chain is about one leaf and one anchor, not a sequence of hops. ## The version delta The conclusion — one peer, one name — holds in every version; only the message carrying the proof changes. - **TLS 1.3**: the server always sends `CertificateVerify`, because the ephemeral exchange is mandatory and static key transport was removed. - **TLS 1.2**: with an ephemeral exchange the server signed its parameters in `server_key_exchange (12)`; with the static RSA key transport that 1.3 removed, it proved possession by being able to decrypt the client's `client_key_exchange(16)`. In 1.2, `CertificateVerify` is the *client's* message, sent in answer to a `CertificateRequest`. ## Using the conclusion 1. **Name the authenticated boundary out loud** when you describe a deployment: "the kiosk authenticates the onboard gateway" is a different sentence from "the kiosk authenticates the booking service", and only one of them is what the protocol did. 2. **Treat every hop past that boundary as unauthenticated** until something other than this handshake authenticates it; the kiosk has no way to inherit a guarantee it never received. 3. **Read the issuer, not only the name**, when you inspect what a client was served — the name will match by construction whenever the handshake succeeded at all.

If the gateway opens its own protected connection onward to the shore-side service, does the kiosk gain any guarantee from it?
No. That is a separate handshake in which the gateway is the client and the kiosk is not a party. The kiosk sees none of its messages and verifies none of its signatures, so whatever it proves, it proves to the gateway about the service — never to the kiosk.
What in the handshake distinguishes an authorised edge holding the key from the origin itself?
Nothing. A certificate binds a key to a name, not to a machine or a network position, so both produce identical messages and identical successful validation. The only in-band hint is the issuer of the served leaf, which an operator can compare against what that host normally presents.
How would you establish how far the guarantee actually reaches?
Out of band. Deployment knowledge of where the handshake is configured to end, plus the issuer of the leaf clients are served, is the evidence; the protocol carries no hop count and no statement about what lies behind the peer that answered.

A signed letter of introduction proves the person at the counter is who they claim to be. It says nothing about the head office they tell you they will forward your request to.

saying these in an interview costs you the question

The certificate proves the response came from the origin server
TLS is end-to-end, so no middle box can complete the handshake
The client can tell from the handshake how many hops are behind its peer
A chain to a trusted anchor means every hop on the path is authenticated
Only an attacker would end a handshake before the origin

A kiosk's TLS handshake to the shore-side booking service ends at an onboard gateway — which peer has the kiosk authenticated?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What the handshake proves

Where the proof stops

Why the kiosk cannot see the difference

The version delta

Using the conclusion

▾common follow-ups3 questions

▾analogy~10 s

▾red flags5 flags

What the handshake proves

Where the proof stops

Why the kiosk cannot see the difference

The version delta

Using the conclusion

answer

go deeper