https证书被中间人截获，信息会被监听吗？

假设A和B通信，B把证书传给A。此时被中间人O拦截到证书，中间人备份一份后发给A。A验证证书也无误。那中间人不就可以拿证书进行中间人攻击了吗？

相当于O变成了A和B沟通的代理。O虽然改不了A的信息，但是感觉O可以伪造是A的信息。

我应该是理解错了，但是不知道那个步骤没理解。请各位大佬指出一下，谢谢。

这个小case太低估了https设计者的集体的智慧了。这些点他们早已想到并防范，还有咱们没有想到的攻击点，他们也想到了。当然基于TLS的https实现并不是100%安全，这种不安全性主要来自于TLS的Code不完美实现，而不是来自于TLS协议本身。

咱们以访问知乎的主页为例，当客户端与知乎服务器建立TLS安全连接时，知乎的服务器会将自己的证书链推送给客户端，通常是三张证书：

• CA证书（根证书，一级证书），用CA自己的私钥给RA签名并背书，自己给自己签名（私钥签名）（1）
• RA证书（二级证书），包含RA明文公钥，用RA自己的私钥给知乎证书签名并背书 （2）
• 知乎证书（叶子证书，三级证书），包含知乎的公钥，知乎的公钥由RA（私钥）签名并担保 （3）

客户端需要验证这个证书链是否和本地操作系统信任证书有任何关联，通常是这么验证的：

• 客户端根据2的RA公钥，验证3的签名是否通过。说的直白一点就是，能否将签名解密？如果可以，进入下一步，否则失败。
• 客户端根据1的CA公钥，验证2的签名是否通过。如果可以，进入下一步，否则失败。
• 客户端使用1的CA公钥，查询本地信任CA证书数据库，如果查询到，则验证通过，否则失败。

终于来到题主的问题了，以上验证过程只是验证这个证书链是合法的，但是这个证书链是从知乎服务器发出的，还是第三方发出的，无法验证，不是吗？

如何确保这个证书链来自于知乎的服务器，而不是第三方呢？

很简单，因为只有知乎服务器才拥有证书链里3的私钥，第三方却没有，是吗？

那只要在安全建立的过程，知乎服务器使用证书3的对应的私钥，对某个关键信息签名不就Okay了吗？

客户端收到这个有签名的关键信息，只要用证书3的公钥尝试解密，成功则意味着签名是知乎私钥签署的，消息报文来自于知乎服务器。否则就是伪造的，失败。

对什么关键信息进行签名呢？

当然对DH公钥进行签名最合理，因为DH算法的公钥没有签名保护，很容易就被中间人攻击了。此举真是一举两得，既证明消息报文来自于知乎服务器，又间接保护了DH公钥，来自于知乎服务器的DH公钥。

双方交换了DH公钥、Nonce，双方就可以推导用于加密http的对称密钥了，整个安全连接建立完成，https加密流量走起。

最后留给读者一个问题，在TLS安全连接建立过程，客户端并没有证书（公钥）也没有自己的私钥，会产生以下几个潜在的问题：

• 客户端的DH公钥如何防范中间人攻击？
• 客户端发出的消息报文由于没有签名保护，如何防范中间人攻击？比如中间人将加密算法修改成最容易破解的算法？

写到这里突然想到本文的问题，如果第三方将知乎服务器的DH公钥（知乎服务器私钥签名）保存下来，下一次直接replay是否可行？

同样不可行，Replay是可以成功欺骗客户端，但是第三方没有知乎的DH私钥啊，因为知乎服务器的DH私钥不在网络上传输，只保存在知乎服务器的内存里，而且一旦会话推出，这个DH私钥就随着内存释放而消失了。