为什么HTTPS中间人攻击仅窃听的时候需要伪造的证书，而不是将服务端的消息原样发回？

在HTTPS中间人攻击的时候，中间人获得了HTTPS请求，并窃听了内容，为什么要使用伪造的证书再发送请求，而不是直接把服务端发来的带有服务端证书的请求重新发给客户端呢？

如果告诉题主，你现在和知乎网站完成https通信，在TLS（Transport Layer Security）层面，知乎服务器需要2个私钥（Private Key），是不是非常震惊、意外？

私钥1：知乎RSA私钥，仅用于证明身份，不参与Key的计算与推导。

私钥2：知乎ECDHE私钥，仅用于Key的计算与推导。

与以上2个私钥一一对应的，知乎还有2个公钥（Public Key）。

公钥1：知乎RSA公钥，仅用于证明身份，不参与Key的计算与推导。

公钥2：知乎ECDHE公钥，仅用于Key的计算与推导。

如何证明身份？

知乎服务器啪啪扔给client 知乎的证书（携带公钥1）、公钥2。

知乎的证书= 公钥1 + CA数字签名（CA的私钥加密）

client肯定很疑惑，如何证明这2个公钥就是知乎的？

校验证书

Client在本地的Root CA数据库查询到CA、CA的公钥。然后用CA的公钥尝试解密上文有下划线的签名。如果失败就报错结束，如果校验成功，说明2件事：

• 签名确实是CA的私钥加密的，否则无法解密（CA私钥、公钥一一映射）。

• 公钥1没有被篡改，否则完整性校验无法通过。

变相说明知乎证书里携带的公钥1，确实是知乎的，值得信任。

既然公钥1已经被信任，它就可以为公钥2做签名。

公钥2 + 用私钥1为公钥2的签名

Client用已经得到的、并被信任的公钥1尝试解密以上有下划线的签名。

如果失败，说明传输过程种被篡改，失败而结束。

如果成功，说明签名为拥有私钥1的服务器加密的。在这个地球上知晓私钥1的，只有知乎服务器。

公钥2，真的就是知乎服务器的。

到此为止，知乎的公钥1、私钥1，完成了历史使命（证明身份），接下来就和他们没有关系了。

接下来就进入激动人心的时刻，双方计算Key了。

Client目前拥有推导Key的所有元素。

• 知乎的公钥2（已经成功验证身份来源、且没有被篡改）

• 知乎的salt( Nonce随机数，不是1分钱一粒的盐粒)

• Client的私钥 （ECDHE私钥，一次性的）

• Client的salt（Nonce随机数）

算法是公开的，至此可以推导出Key。

知乎服务器也拥有推导Key的所有元素。

• 知乎的私钥2（ECDHE，一次性的）

• 知乎的salt( Nonce随机数)

• Client的公钥 （ECDHE公钥，一次性的）

• Client的salt（Nonce随机数）

算法是公开的，至此也可以推导出Key’。

如果在传输过程中，有第三方篡改有下划线的部分，失败而结束。

如果在传输过程中，没有第三方篡改有下划线的部分，恭喜恭喜！

Key = Key’

到此为止，所有的公钥私钥全部退出历史舞台，接下来就是Key的solo时间。

Key + 对称AES加密算法，就可以完成https流量的加密、解密了。

接下来简单回答问题。

要想成功欺骗client，中间人需要有2个私钥。

如果中间人仅仅用伪造的证书（公钥1）成功欺骗Client，而不用自己的公钥2替换服务器的公钥2的话，很显然，无法成功。因为中间人没有服务器的私钥2（与服务器的公钥2对应）。

只要仔细阅读上文推导需要的4元素，很容易就可以得出以上结论。

有读者可能会抗议，老早不是服务器只要一个RSA私钥就可以完成Key的交换与推导的吗？

是的，只要client用服务器的RSA公钥加密一个pre-maste-key，然后服务器用RSA私钥解密，得到明文的pre-maste-key，双方有可以推导出相同的Key。

如果是这种情况，只要用伪造证书替换真实服务器的证书，即可成功。

但是，用RSA公钥分享Key的方法显然不满足PFS (Perfect Forward Security)，故慢慢地被边缘化并最终被抛弃！

以上。

原文始发于微信公众号（车小胖谈网络）：为什么HTTPS中间人攻击仅窃听的时候需要伪造的证书，而不是将服务端的消息原样发回？