authentication - 发送客户端证书如何不将客户端暴露给模拟

Question

好吧，为了便于交流，我将引用这张图片

好的，所以服务器会发送一个公钥，客户端使用它来加密自己的证书信息以发送回服务器。我不明白的是为什么攻击者无法拦截来自步骤 4 的数据包，然后使用它发送到服务器以冒充客户端。他们不必知道里面的信息或解密它。如果攻击者获得并保存了该数据包，他们就可以在服务器请求客户端证书时将这些确切的字节发送到服务器。我不确定这种加密方法如何防止这种类型的攻击。话又说回来，在套接字级加密方面我完全是菜鸟，所以我可能会遗漏一些重要的东西。谢谢!

Answer 1

事情比那更复杂，这张图有一些缺陷，混合了本地存储和交换的东西。

看看https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake特别是“客户端验证的 TLS 握手”案例。

总结:

• 有时服务器会要求客户端发送证书(这并不总是需要的，因此服务器会发送一条特定的消息来请求它，CertificateRequest)
• 然后客户端回复一条包含其证书的Certificate消息
• 在那个阶段，服务器已经可以根据提供的证书决定是否要继续；确实在那个阶段其他人也可以发送相同的证书，因为它是公开的。但接下来的内容解释了为什么它在 TLS 握手中无法进一步工作
• 在来自服务器的包含各种加密数据的 ClientKeyExchange 消息之后，这些数据稍后将用于真正加密应用程序数据的交换，
• 客户端发送一个CertificateVerify 消息，它是在之前握手中的 TLS 消息交换上计算的签名，使用与客户端证书关联的私钥
• 收到此消息的服务器可以仔细检查它是否正在与真正的客户端通话，因为通过尝试使用客户端公钥(包含在证书中)验证签名，它会知道远程方是否确实具有正确的关联私有(private)键与否。

因此，攻击者不能仅通过窃取证书来冒充客户端(在另一种情况下存在相同类型的保护，以验证服务器)，当然只要私钥保持私密即可。如果私钥被盗，则上述所有操作都将失败。

在这一点上没有必要了解加密签名的所有细节，只是系统的设计方式使得由其中一个 key 加密的所有内容只能由另一个 key 解密:如果有人用它的私钥，那么任何人都可以用它的公钥解密它(根据定义，它是公开的；然后你通常会遇到传播它的问题，但这里没有，因为公钥包含在证书中，只是交换在握手之前)；这当然对保密性毫无用处(任何人都可以看到加密的内容)，但它是身份验证的基础，因为如果解密有效，则意味着发件人拥有与您用来解密的公钥相关联的私钥。

请注意，对于刚刚作为新标准发布的 TLS 1.3，TLS 交换中消息的数量和性质略有变化，但上述加密保证(使用私钥签署某些内容，以便远程方可以加倍-检查关联的公钥)仍然有效。