前置说明

在学习 https 过程中，对于如何防止中间人攻击（MITMA）抱有疑问。

经了解发现，客户端是通过第三方机构 CA（Certificate Authorities）颁发的 SSL 证书验证服务器身份，之后再通过非对称加密的形式，协商对称加密的密钥，以此来实现安全通信。

对于非对称加密协商对称加密密钥这个过程，网上有很多学习资源，但对于 SSL 证书验证服务器身份流程的资源却很少。

所以，为了方便记忆，对SSL证书验证流程进行梳理和记录。

如有错误，请大家指正，谢谢。

数字签名

我们都知道，SSL 证书如果需要具有验证身份功能的话，无非是需要保证两点：

颁发机构权威防篡改

发放 SSL 证书的机构都知道是 CA 机构，这没什么好说的。

主要是防篡改， SSL 证书是通过数字签名的方式，防止中间人（MITM）篡改公钥的。

下面对整个加密验证过程进行梳理。

1. 首先服务机构向 CA 申请 SSL 证书，提供企业信息，法人联系方式，域名等等企业信息。CA 机构验证后，会先自己生成一个证书，可以理解为可读的明文。（实际上是一个特定格式的数据文件，但此处为了理解做出抽象）

2. 验证通过，生成证书后， CA 机构会对明文证书进行Hash，得到摘要信息，并将摘要信息使用 CA 私钥 进行加密得到数字签名。之后将 证书明文内容+数字签名 返回到服务机构。

3. 当客户端和服务器握手时，服务器将 CA 机构生成的 证书明文内容+数字签名 发送给客户端。客户端通过操作系统或者浏览器内置信任的CA机构找到对应CA机构的公钥对数字签名进行解密，然后采用同样的摘要算法计算SSL证书的摘要，如果自己计算的摘要与服务器发来的摘要一致，则证书是没有被篡改过的！

注意： 一个是CA的公钥，内置在客户端，用来解密数字签名！另一个是目标服务器的公钥，在SSL证书内容里，用来协商对称密钥！

总结

1. 如何防止中间人攻击（MITMA）？

因为无论是什么机构都是没有 CA 私钥的（只有CA自己有），所以当中间人在修改协商公钥后，无法对数字签名重新加密。即使重新加密，在客户端用 CA 公钥解密后，因为中间人不是采用CA私钥加密的，所以客户端会发现多种摘要信息对比错误（例如企业信息、域名等等），这是就能判断，证书信息被修改过，正在握手的服务器不可信。

参考文章