HTTPS协议自我总结之二 证书加密，验证，通信流程

上一篇分析了一下SSL/TSL的握手过程，这一篇我们就讲解一下，从申请CA证书到客户端证书校验的整体过程。还是以一幅图来进行说明。

1. 服务端会生成一对公钥和私钥，拿着如下信息：

a. 公司组织名称域名

b. 服务器公钥

c. 服务器公钥到期时间

等等信息去CA认证的公司去申请证书。

2. CA公司收到申请后会通过各种渠道去考察公司的资质， 如果考察通过，则会给公司

一个证书， 里面包含了明文信息：

a. 公司组织名称域名

b. 服务器公钥

c. 服务器公钥到期时间

e. 颁发此证ID的CA机构

f. 一个唯一的*** 等

然后将这些明文信息通过散列算法如MD5/SHA1/SHA256等生成一串唯一数据，然后

通过CA机构的私钥对这串字串进行签名。这就是证书。

3. CA机构将证书给到公司，这样在上一篇文章中的第二部服务器返回给到客户端的证书

就是现在CA颁发给公司的证书。

4. 在上一篇中也提到了客户端会对服务端给到的证书进行校验， 那么这个校验的过程是

如何进行的呢， 如下：

a. 现在市面上的各种操作系统会将这些CA机构的根证书植入进去， 里面包含了CA

机构的公钥和各类信息。

b. 当客户端拿到服务端返回的证书后会通过操作系统CA机构的公钥对这个证书进行

数字认证， 如果公钥能匹配该证书的数字签名则说明证书是CA颁发的受信任的

证书。如果校验不通过， 则无法继续进行握手。

c. 如果证书校验通过了， 这个时候通过公钥可以得到证书的明文信息和第2步中，

服务器通过明文信息加密后产生的唯一数据。客户端再对证书中的明文通过同样的

散列算法生成一串数据， 拿两个数据进行比对看是否一致， 校验数据是否有被更改

过。 这也是防止中间人劫持的重要方式。如果比较一致， 则说明证书是有效的，则

里面的公钥也是有效的， 这样就拿到了我们服务器端的公钥。就有了上一篇文中

提到的，客户端对所有参数进行散列算法加密生成的字串用公钥进行加密，这个公钥

就是现在所得到的公钥。

5. 接下来就是上一篇文章中证书校验后的步骤了。

 

中间人劫持

提到这里我们就要假设下中间人攻击或者拦截，首先要考虑的就是校验证书这一块

了。我们做个最简单的例子， 拿抓包工具fiddler来做例子，看看他们是作为中间人实现抓包的：

查看上述的验证过程，漏洞可以如下：

1. 中间人先将自己的根证书埋入到系统中；

2. 当客户端像服务端请求的时候，中间人例如fiddler会先进行拦截。 这时，fiddler会把

自己的自制的证书返回给客户端，客户端并不知道被拦截了返回的并不是自己服务端

的证书。

3. 客户端拿到fiddler返回的证书后进行校验， 因为fiddler已经将根证书植入系统了，客户

端通过根证书去校验的时候，是用fidder的公钥去匹配fiddler通过自己的私钥签名后传

过来的证书，这样是匹配的，是可以通过的。这样之后的握手就都是跟fiddler之间的

握手了。都可以通过。

4. fiddler会拿到劫持的客户端的参数去模拟客户端请求我们的服务器，这又是同样的一

套客户端和服务端的握手过程了。拿到服务器返回的数据，再返回给我们客户端。

 

如何防止抓包：

1. 本地证书校验： 本地放入公司的CA证书，在请求的时候校验服务器返回的证书是否

跟我们本地的证书是一致的。比如上述例子， 如果我们本地有公司的证书， 拿着

证书去匹配fiddler给我们的自制的证书，肯定是无法匹配通过的。

缺点：证书如果过期需要更新版本。

 

2. 强域名校验：开启强域名校验后，请求的时候我们会去校验域名，显然上述例子就算

客户端证书校验通过了， 但是在请求中校验域名的时候是无法通过的， 因为每个公

司的域名都是不一样的。

 

3. 二次加密： 在于服务端的通信中开启二次加密即所有的参数在通过https之前先进行

一道加密。如AES+**加密。https内部的参数传输采用的也是这种对称加密算法，

速度快。这样就算中间人拿到了也**不了。