HTTPS抓包详细分析
Posted 席飞剑
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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为空。
HTTPS请求流程分析