发送客户端证书如何不会使客户端受到模拟

时间:2018-10-18 17:03:20

标签: sockets authentication ssl mutual-authentication

好的,为了方便沟通,我将参考这张图片description of TLS mutual authentication

好的,因此服务器发送一个公共密钥,客户端使用该公共密钥对自己的证书信息进行加密以发送回服务器。我不明白的是,为什么攻击者无法拦截第4步中的数据包,然后使用该数据包将其发送到服务器来模拟客户端。他们不必知道内部信息或对其进行解密。如果攻击者获得了该数据包并将其保存,则他们可以在服务器请求客户端证书时将这些确切的字节发送到服务器。我不确定这种加密方法如何防止这种攻击。再说一遍,对于套接字级加密,我是一个菜鸟,所以我可能会错过一些大的东西。谢谢!

2 个答案:

答案 0 :(得分:1)

事情要复杂得多,这张图片有一些缺陷,并且在本地存储的内容和交换的内容之间混合了一些东西。

看看https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake,尤其是“经客户端认证的TLS握手”案例。

总结:

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

因此,只要私钥仍然是私有的,攻击者就不能仅通过窃取证书来冒充客户端(在另一种情况下,存在相同类型的保护,以对服务器进行身份验证)。如果私钥被盗,则上述所有操作都会失败。

此时,无需了解加密签名的所有详细信息,只需对系统进行设计,使通过其中一个密钥加密的所有内容只能由另一个密钥解密:如果有人使用它的私钥,那么任何人都可以使用其公钥(根据定义,它是公钥)对其进行解密;然后,您通常会遇到传播它的问题,但是这里没有,因为公钥包含在被交换的证书中在握手之前);当然,这对于保密性毫无用处(任何人都可以看到加密的内容),但这是身份验证的基础,因为如果解密有效,则意味着发件人拥有与您用来解密事物的公用密钥相关的私钥。

请注意,对于仅希望作为新标准的TLS 1.3,TLS交换中消息的数量和性质已经稍有变化,但是上述加密保证(使用私钥签名的东西使远程方可以加倍使用)并使用相关的公钥检查)仍然有效。

答案 1 :(得分:0)

除了 Patrick's 答案之外,还会比较 mTLS 期间的时间戳。如果传入的时间戳超过了某个限制,则会话被放弃,因此您拦截的数据包将变得无用。

https://en.wikipedia.org/wiki/Mutual_authentication#Defenses