TLS-Handshake 基于用于对称密钥交换的公钥加密，用于服务器身份验证的 pki，并假设用户身份验证是通过应用层中的用户名和密码实现的。使用通道绑定时，将在较低层绑定哪种身份验证？
在 RFC 5929 中：
通道绑定的概念允许应用程序通过将较高层的身份验证绑定到较低层的通道来确定一个网络层的安全通道的两个端点与较高层的相同。这允许应用程序将会话保护委托给较低层，这具有各种性能优势。
通道绑定有什么好处？有人可以轻松解释频道绑定吗？也许以通道绑定类型 tls-server-end-point 为例？
通道绑定的动机之一是防止能够捕获用户身份验证凭据（例如 OAuth 令牌、会话标识符等）的攻击者在另一个 TLS 会话中重用这些凭据。通过将这些凭据绑定到使用它们的 TLS 会话的唯一指纹（通过通道绑定），它们不能在攻击者发起的另一个 TLS 会话中重用。
想要查询更多的信息：
TLS 通道绑定旨在防止 MitM 暴露 Secret（密码）和 Data。SASL-SCRAM 本身的工作方式允许在不传递密码的情况下进行身份验证 - 密码用作共享机密，以对共享的非机密（随机数）执行加密操作。这可以防止 MitM 暴露凭据，但它不会阻止数据的暴露- MitM 代理应该等到您完成身份验证，然后它将拥有对数据的完全访问权限。
TLS 最初旨在防止这种情况（服务器身份验证），但它依赖于Trust，这是当今罕见的商品。企业解密代理为内容分析创建气隙是一种常见的做法，无论他们有什么好的意图——它们都是破坏 TLS 连接的机密性和完整性的中间人。当受信任的 CA 签名密钥外泄时，也会发生同样的情况。
发明了各种技术来缓解这种情况，例如OCSP 装订、DANE TLS、密钥固定——主要依靠某种 OOB 协议/基础设施来验证证书不仅在一般情况下是受信任的，而且是值得信任的。特定的服务。
因此，本质上SASL-SCRAM-*-PLUS机制（这是 TLS 通道绑定的最常见实现）是实现这一目标的另一种方法 - 但是现在使用带内通道，不依赖任何其他组件。
Channel Binding 强制客户端和服务器之间的信任，以便客户端通知服务器它认为它与谁说话，服务器验证它是否正确。因此，现在如果您通过公司 MitM 代理服务器将拒绝客户端的身份验证，因为客户端将传递不同的信任锚详细信息。这里的信任锚是指通道绑定数据。
在tls-server-end-point方法的情况下，它只是带内证书固定的另一种方法。客户端直接（摘要）和间接（hmac）传递它所连接的证书的指纹，如果服务器检测到这与它实际使用的证书不匹配，它将简单地拒绝身份验证。使用此绑定方法的证书固定允许您使用与通道绑定内联的现有反向代理/tls-offload/负载平衡机制，但保留现有的弱点 - 静态绑定数据（启用前映像攻击）和密钥盗窃。与信任锚是 TLS 会话密钥材料的 tls-unique 相比，即使攻击者拥有您的证书+密钥服务器，仍然会检测到 TLS 随机数的差异。
最终结果是 - 您的凭据 (SCRAM-) 和您的数据 (-PLUS) 都不会暴露给 MitM，因为如果服务器检测到完整性受损，它会拒绝接受您的身份验证。