好的,因此服务器发送一个公共密钥,客户端使用该公共密钥对自己的证书信息进行加密以发送回服务器。我不明白的是,为什么攻击者无法拦截第4步中的数据包,然后使用该数据包将其发送到服务器来模拟客户端。他们不必知道内部信息或对其进行解密。如果攻击者获得了该数据包并将其保存,则他们可以在服务器请求客户端证书时将这些确切的字节发送到服务器。我不确定这种加密方法如何防止这种攻击。再说一遍,对于套接字级加密,我是一个菜鸟,所以我可能会错过一些大的东西。谢谢!
答案 0 :(得分:1)
事情要复杂得多,这张图片有一些缺陷,并且在本地存储的内容和交换的内容之间混合了一些东西。
看看https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake,尤其是“经客户端认证的TLS握手”案例。
总结:
CertificateRequest
)Certificate
消息,其中包含其证书ClientKeyExchange
消息之后,其中包含各种加密数据,这些消息将在以后用于真正加密应用程序数据的交换,CertificateVerify
消息,该消息是通过与客户端证书相关联的 private 密钥完成的,在握手之前根据TLS消息交换计算得出的签名因此,只要私钥仍然是私有的,攻击者就不能仅通过窃取证书来冒充客户端(在另一种情况下,存在相同类型的保护,以对服务器进行身份验证)。如果私钥被盗,则上述所有操作都会失败。
此时,无需了解加密签名的所有详细信息,只需对系统进行设计,使通过其中一个密钥加密的所有内容只能由另一个密钥解密:如果有人使用它的私钥,那么任何人都可以使用其公钥(根据定义,它是公钥)对其进行解密;然后,您通常会遇到传播它的问题,但是这里没有,因为公钥包含在被交换的证书中在握手之前);当然,这对于保密性毫无用处(任何人都可以看到加密的内容),但这是身份验证的基础,因为如果解密有效,则意味着发件人拥有与您用来解密事物的公用密钥相关的私钥。
请注意,对于仅希望作为新标准的TLS 1.3,TLS交换中消息的数量和性质已经稍有变化,但是上述加密保证(使用私钥签名的东西使远程方可以加倍使用)并使用相关的公钥检查)仍然有效。
答案 1 :(得分:0)
除了 Patrick's 答案之外,还会比较 mTLS 期间的时间戳。如果传入的时间戳超过了某个限制,则会话被放弃,因此您拦截的数据包将变得无用。
见https://en.wikipedia.org/wiki/Mutual_authentication#Defenses。