TLS-Handshake is based on public-key cryptography for symmetric key exchange, pki for server-authentication and assume the user authentication is realized trough username and password in the application layer. Wich authentication will be bind at the lower layer when channel binding is used?

In RFC 5929:

The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.

What are the advantages of channel binding? Can someone please explain channel binding easily? Maybe with the channel binding type tls-server-end-point as an example?

3 Answers 3


One of the motivations for channel binding is to prevent an attacker who is able to capture users' authentication credentials (e.g. OAuth tokens, session identifiers, etc) from reusing those credentials in another TLS session. By tying these credentials to a unique fingerprint of the TLS session in which they are used (by way of channel binding), they cannot be reused in another TLS session initiated by the attacker.

For more information:


TLS Channel binding is targetting to prevent MitM exposure of the both Secret (password) and Data. SASL-SCRAM itself works in a way that it allows authentication without passing the password - password is used as shared secret to perform cryptographic operations on shared non-secret (nonce). That prevents MitM exposure of credentials however it does not prevent exposure of the Data - MitM proxy should just wait till you complete the Authentication and then it will have full access to the Data.

TLS initially was designed to prevent that (server authentication) however it relies on Trust, which is a rare commoditiy nowadays. Enterprise decrypting proxies creating airgap for content analysis is a common practice, and whatever good intentions they have - they are MitMs which are breaking confidentiality and integrity of the TLS connection. Same situation happens when trusted CA signing key leaks out to the wild.

Various technologies were invented to mitigate this, things like OCSP stapling, DANE TLS, Key Pinning - mostly relying on some sort of OOB protocol/infrastructure to verify certificate is not just trusted in general but is the one what was meant to be trusted for this particular service.

So in the essence SASL-SCRAM-*-PLUS mechanisms (which is the most common implementation of the TLS Channel Binding) is another method to achieve that - now using inband channel however, not relying on any other components.

Channel Binding enforces the trust between client and server, so that Client informs the server whom it thinks it speaks to, and Server validates whether it is correct or not. So now if you are passing via corporate MitM proxy server will reject client's authentication because the Client would pass different trust anchor details. And by trust anchor here is meant Channel Binding data.

In case of tls-server-end-point method it is just another method of inband certificate pinning. Client directly (digest) and indirectly (hmac) passes fingerprint of the certificate it is connected to and if server detects this is not matching to the certificate it actually uses it will simply reject authentication. Certificate pinning using this binding method allows you to use existing reverse-proxy/tls-offload/load-balancing mechanisms inline with channel binding but maintains existing weaknesses - static binding data (enabling pre-image attack) and key theft. Compare to tls-unique where trust anchor is TLS session keying material - so even if attacker has your cert+key server would still detect difference in TLS nonces.

Net result is - neither you credentials (SCRAM-) nor your data (-PLUS) is exposed to MitM as server refuses to accept your authentication if it detects broken integrity.


While other answers are correct, I believe NTLM relaying against ADCS should be present here as a great example. The attack is described here in detail:


The gist is that in many cases Windows servers can be coerced to perform NTLM authentication to the attacker, and the attacker can relay the credentials to another services, Certificate Services in this case. This results in a certificate being created for the coerced server, that can be retrieved by the attacker. The CS runs over HTTP by default.

The recommendation by Microsoft is to configure Extended Protection for Authentication:


The implementation is described in detail here:


In summary, by binding the NTLM authentication to the TLS channel the server can check if the received NTLM authentication response was meant for it by comparing the server certificate hash with the one provided in the message, thus relayed messages will be rejected.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .