If a relay target only accepts TLS, what does channel binding add that TLS alone does not?
answer
- the operator is an endpoint, not a listener
- two valid tunnels, one payload
- hash of the certificate you are talking to
- which connection, and which service
- useless versus invalid
basics
~20 sTLS protects one hop, and the operator is a valid endpoint of two of them. The authentication inside names neither channel. Channel binding mixes the target's certificate into the response, so a reply minted over one channel is refused on the other.
solid answer
~50 sA TLS tunnel gives confidentiality and integrity between its two endpoints, and the relay operator is an endpoint on both sides: one TLS session with the coerced host, another with the target. Both are perfectly valid. The authentication carried inside says nothing about which of them it travelled through, so it moves between them freely. Channel binding removes that freedom: the client derives a value from the target's TLS certificate and mixes it into its authentication response, and the server checks that value against its own channel. A response minted over the operator's channel then fails on the target's. Service binding is the companion property: the client states the service name it meant to reach and the server refuses a mismatch. Together they give the exchange an audience. Kerberos has this by construction - a service ticket is encrypted with the target service's own key, so it cannot be handed to a different service.
code
text · 15 linesAUTHENTICATE message (NTLMv2 response) - the fields that decide relay
NTProofStr = HMAC(key derived from the account secret,
server challenge + blob)
blob AV_PAIRs:
MsvAvNbDomainName = CORP
MsvAvNbComputerName = FILE01 <- echoed from the challenge the client
received, i.e. whatever destination the
operator forwarded to: no evidential value
MsvAvTimestamp = ...
MsvAvChannelBindings = <absent> <- nothing ties this response to the TLS
channel it was carried over
MsvAvTargetName = <absent> <- nothing names the service it was meant for
MIC = keyed over the three handshake messages
(integrity of the exchange, not of its audience)
...go deeper
Know that encryption protects a single connection between two endpoints, and that a party who terminates one connection and opens another is an endpoint of both, not an eavesdropper.
Explain the endpoint binding mechanism: the client hashes the certificate it was shown, includes it in the response, and the server compares with the certificate it actually presented.
Distinguish invalid from useless - binding causes rejection at acceptance while signing denies the session afterwards - and check whether binding is enforced rather than merely supported.
Own the decision to require binding at the services that accept identities, knowing that permissive modes exist for old clients and that leaving one in place forfeits the property entirely.
## The mistake this question is built on The intuitive defence is that if the traffic is encrypted, nobody in the middle can meddle with the authentication. That is true and irrelevant. The operator is not in the middle of one TLS session; the operator is a legitimate endpoint of two. On the first, the coerced host connects to the operator and completes a normal TLS handshake with whatever certificate the operator presents. On the second, the operator connects to the real target and completes a normal TLS handshake with the target's certificate. Both sessions are cryptographically sound. The operator simply reads the authentication out of one and writes it into the other. Encryption protected each hop exactly as designed and did nothing at all about the hop-to-hop copy, because the payload never claimed to belong to a particular hop. ## What channel binding changes Channel binding closes the gap by making the authentication depend on the transport it is carried over. The standard mechanism for TLS is an endpoint binding: the client takes a hash of the server certificate presented on the connection it is using and includes that value inside its authentication response. The server, which knows which certificate it presented, recomputes the expected value and compares. Apply that to the two-session picture. The coerced host is talking to the operator, so it binds to the operator's certificate. The operator forwards the response to the target, which presented a different certificate. The values disagree and the target refuses the authentication - not later, at the first request, but immediately, as part of accepting the identity. That is the qualitative difference from session signing: signing makes a forwarded authentication *useless*; binding makes it *invalid*. ## Service binding, the companion property Binding to a channel answers the question *which connection was this for*. Service binding answers *which service was this for*. The client includes the service name it believed it was contacting in its response, and the server compares it to its own name. A relay operator can only offer what the coerced host produced, and the coerced host named the destination it was pointed at. These two together are what the leaf's central claim reduces to: a forwarded authentication is worthless exactly when the exchange carries an audience the far end can check. Everything else - signing, transport encryption, password strength, rotation - either fails to address the audience question or attacks a different part of the problem. ## The record, read carefully One subtlety rewards attention. The authentication response also carries descriptive fields about the target, copied from the challenge the client received. Those fields do not help: the challenge the coerced host received was relayed from the real target by the operator, so the fields describe the operator's chosen destination, not the client's intent. Only values the *client* originates and the *server* independently verifies have any force. That is why an endpoint certificate hash works and an echoed server name does not. ## Kerberos as the contrast It is worth being able to say why the same manoeuvre does not generalise. A Kerberos service ticket is issued for a named service and encrypted with that service's own key. A different service cannot decrypt it, so handing it on is pointless: the audience is baked into the object rather than checked by a comparison. That is service binding by construction rather than by option, and it is the cleanest illustration of what the relayable design is missing. ## Practical consequences Three things follow for anyone choosing controls. First, TLS in front of a service is not a relay control and should never be cited as one. Second, binding must be *enforced* to matter - a service that accepts responses with the binding field absent is in the same position as one that never asked, and compatibility with older clients is the usual reason it ends up permissive. Third, the enforcement point is the service that accepts the identity: the coerced host will bind to whatever it is talking to, and only the far end can notice that the value is wrong. A candidate who can state that the operator holds two valid TLS sessions, and that the fix is to make the authentication depend on which one it travelled over, has the whole answer.
- The response already carries the target's computer name. Why does that not stop a relay?Because that field is echoed from the challenge the client received, and the operator relayed that challenge from the destination they chose. It describes the operator's target, not the client's intent. Only a value the client originates and the server independently verifies - a hash of the certificate it presented, or the service name it owns - has any force.
- How is this different from what session signing achieves?Signing lets the authentication succeed and then denies the session to a party with no key, so the forwarded copy is useless. Binding makes the far end reject the authentication itself as invalid, because the value describing the channel or the service does not match. One removes the prize, the other removes the acceptance.
- Why is Kerberos not relayable the same way?A service ticket is issued for one named service and encrypted with that service's own key, so another service cannot read it. The audience is part of the object rather than a field to be checked, which is service binding by construction.
A sealed envelope is not addressed. Anyone who receives one can drop it in a different postbox, and both journeys are perfectly secure.
saying these in an interview costs you the question
- Says an encrypted transport prevents relay
- Thinks the operator must break TLS to relay through it
- Cites the echoed server name field as an audience check
- Confuses channel binding with certificate pinning by the client
- Assumes a binding field present but unverified still protects