HTTPS抓包详细分析

专题二：实际抓包分析

本文对百度搜索进行了两次抓包，第一次抓包之前清理了浏览器的所有缓存；第二次抓包是在第一次抓包后的半分钟内。

百度在2015年已经完成了百度搜索的全站https，这在国内https发展中具有重大的意义（目前BAT三大家中，只有百度宣称自己完成了全站HTTPS）。所以这篇文章就以www.baidu.com为例进行分析。

同时，作者采用的是chrome浏览器，chrome支持SNI （server Name Indication） 特性，对于HTTPS性能优化有很大的用处。

注：SNI是为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是：在和服务器建立SSL连接之前，先发送要访问的域名（hostname），这样服务器根据这个域名返回一个合适的证书。目前，大多数操作系统和浏览器都已经很好地支持SNI扩展，OpenSSL 0.9.8已经内置这一功能，新版的nginx和apache也支持SNI扩展特性。

本文抓包访问的URL为：http://www.baidu.com/  

（如果是https://www.baidu.com/，则以下结果不一样！）

抓包结果：

可以看到，百度采用以下策略：

（1）对于高版本浏览器，如果支持 https，且加解密算法在TLS1.0 以上的，都将所有 http请求重定向到 https请求

（2）对于https请求，则不变。

【详细解析过程】

1、TCP三次握手

可以看到，我的电脑访问的是http://www.baidu.com/，在初次建立三次握手的时候， 客户端是去连接 8080端口的（我所在小区网络总出口做了一层总代理，因此，客户端实际和代理机做的三次握手，代理机再帮客户端去连接百度服务器）

2、tunnel建立

由于小区网关设置了代理访问，因此，在进行https访问的时候，客户端需要和代理机做"HTTPS CONNECT tunnel" 连接（关于"HTTPS CONNECT tunnel"连接，可以理解为：虽然后续的https请求都是代理机和百度服务器进行公私钥连接和对称密钥交换，以及数据通信；但是，有了隧道连接之后，可以认为客户端也在直接和百度服务器进行通信。）

fiddler抓包结果：

3、client hello

3.1 随机数

在客户端问候中，有四个字节以Unix时间格式记录了客户端的协调世界时间（UTC）。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数。在这个例子中，0x2516b84b就是协调世界时间。在他后面有28字节的随机数（random_C），在后面的过程中我们会用到这个随机数。

3.2 SID（Session ID）

如果出于某种原因，对话中断，就需要重新握手。为了避免重新握手而造成的访问效率低下，这时候引入了session ID的概念， session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的“对称密钥”，而不必重新生成一把。

因为我们抓包的时候，是几个小时内第一次访问https://www.baodu.com ，因此，这里并没有Session ID.（稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID）  

session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器（这是很有可能的，对于同一个域名，当流量很大的时候，往往后台有几十台RS机在提供服务），就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。

3.3 密文族（Cipher Suites）

RFC2246中建议了很多中组合，一般写法是"密钥交换算法-对称加密算法-哈希算法，以“TLS_RSA_WITH_AES_256_CBC_SHA”为例：

（a）TLS为协议，RSA为密钥交换的算法；

（b）AES_256_CBC是对称加密算法（其中256是密钥长度，CBC是分组方式）；

（c）SHA是哈希的算法。

浏览器支持的加密算法一般会比较多，而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。（比如综合安全性以及速度、性能等因素）

3.4 Server_name扩展（一般浏览器也支持 SNI扩展）

当我们去访问一个站点时，一定是先通过DNS解析出站点对应的ip地址，通过ip地址来访问站点，由于很多时候一个ip地址是给很多的站点公用，因此如果没有server_name这个字段，server是无法给与客户端相应的数字证书的，Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。

服务器回复

（包括Server Hello，Certificate，Certificate Status）

服务器在收到client hello后，会回复三个数据包，下面分别看一下：

4、Server Hello

4.1、我们得到了服务器的以Unix时间格式记录的UTC和28字节的随机数 （random_S）。

4.2、Seesion ID，服务端对于session ID一般会有三种选择  （稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID）：

（1）恢复的session ID：我们之前在client hello里面已经提到，如果client hello里面的session ID在服务端有缓存，服务端会尝试恢复这个session；

（2）新的session ID：这里又分两种情况，第一种是client hello里面的session ID是空值，此时服务端会给客户端一个新的session ID，第二种是client hello里面的session ID此服务器并没有找到对应的缓存，此时也会回一个新的session ID给客户端；

（3）NULL：服务端不希望此session被恢复，因此session ID为空。

4.3、我们记得在client hello里面，客户端给出了多种加密族 Cipher，而在客户端所提供的加密族中，服务端挑选了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”

（a）TLS为协议，RSA为密钥交换的算法；

（b）AES_256_CBC是对称加密算法（其中256是密钥长度，CBC是分组方式）；

（c）SHA是哈希的算法。

这就意味着服务端会使用ECDHE-RSA算法进行密钥交换，通过AES_128_GCM对称加密算法来加密数据，利用SHA256哈希算法来确保数据完整性。

5、Certificate

在前面的https原理研究中，我们知道为了安全的将公钥发给客户端，服务端会把公钥放入数字证书中并发给客户端（数字证书可以自签发，但是一般为了保证安全会有一个专门的CA机构签发），所以这个报文就是数字证书，4097 bytes就是证书的长度。

我们打开这个证书，可以看到证书的具体信息，这个具体信息通过抓包报文的方式不是太直观，可以在浏览器上直接看。（点击chrome浏览器左上方的绿色锁型按钮） 

6、Server Hello Done

我们抓的包是将 Server Hello Done  和 server key exchage 合并的包：

7、客户端验证证书真伪性

客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：

（1）证书链的可信性trusted certificate path，方法如前文所述；

（2）证书是否吊销revocation，有两类方式离线CRL与在线OCSP，不同的客户端行为会不同；

（3）有效期expiry date，证书是否在有效时间范围；

（4）域名domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析； 

8、秘钥交换

这个过程非常复杂，大概总结一下：

（1）首先，客户端利用CA数字证书实现身份认证，利用非对称加密协商对称密钥。

（2）客户端会向服务器传输一个“pubkey”随机数，服务器收到之后，利用特定算法生成另外一个“pubkey”随机数，客户端利用这两个“pubkey”随机数生成一个 pre-master 随机数。

（3）客户端利用自己在 client hello 里面传输的随机数 random_C，以及收到的 server hello 里面的随机数 random_S，外加 pre-master 随机数，利用对称密钥生成算法生成 对称密钥enc_key：enc_key=Fuc(random_C, random_S, Pre-Master)

9、生成session ticket

如果出于某种原因，对话中断，就需要重新握手。为了避免重新握手而造成的访问效率低下，这时候引入了session ID的概念， session ID（以及session ticke）的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的“对话密钥”，而不必重新生成一把。

因为我们抓包的时候，是几个小时内第一次访问 https://www.baodu.com 首页，因此，这里并没有 Session ID.（稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID） 

session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。

后续建立新的https会话，就可以利用 session ID 或者 session Tickets ， 对称秘钥可以再次使用，从而免去了 https 公私钥交换、CA认证等等过程，极大地缩短 https 会话连接时间。

10、利用对称秘钥传输数据

三、半分钟后，再次访问百度：

有这些大的不同：

由于服务器和浏览器缓存了 Session ID 和 Session Tickets，不需要再进行 公钥证书传递，CA认证，生成 对称密钥等过程，直接利用半分钟前的对称密钥加解密数据进行会话。

1、Client Hello

2、Server Hello