为什么我抓不到baidu的数据包

64 bytes from 39.156.66.10 (39.156.66.10): icmp_seq=3 ttl=49 time=30.6 ms

从上面的结果可以知道请求baidu.com时会去访问39.156.66.10。


于是用下面的[tcpdump]( )命令进行抓包，大概的意思是抓eth0网卡且ip为39.156.66.10的网络包，保存到baidu.pcap文件中。

$ tcpdump -i eth0 host 39.156.66.10 -w baidu.pcap

此时在浏览器中打开baidu.com网页。或者在另外一个命令行窗口，直接用curl命令来模拟下。

$ curl ‘https://baidu.com’

按理说，访问baidu.com的数据包肯定已经抓下来了。


然后停止抓包。


再用wireshark打开baidu.pcap文件，在过滤那一栏里输入http.host == “baidu.com”。


此时发现，一无所获。


![图片](https://img-blog.csdnimg.cn/a62c43398eeb4b41ac0aa7317dc4201a.png)


在wireshark中搜索baidu的包，发现一无所获


这是为啥？


到这里，有经验的小伙伴，其实已经知道问题出在哪里了。


### 为什么没能抓到包


这其实是因为他访问的是HTTPS协议的baidu.com。HTTP协议里的Host和实际发送的request body都会被加密。


正因为被加密了，所以没办法通过http.host进行过滤。


但是。


虽然加密了，如果想筛选还是可以筛的。


HTTPS握手中的Client Hello阶段，里面有个扩展server\_name，会记录你想访问的是哪个网站，通过下面的筛选条件可以将它过滤出来。


![图片](https://img-blog.csdnimg.cn/499e981d85b14b0b8589c39e7499907d.png)


通过tls的扩展server\_name可以搜索到baidu的包


此时选中其中一个包，点击右键，选中Follow-TCP Stream。


![图片](https://img-blog.csdnimg.cn/aa4554750a8841ebb1d3ee6ee58f4cb1.png)


右键找到tcp 流


这个TCP连接的其他相关报文全都能被展示出来。


![图片](https://img-blog.csdnimg.cn/3f17c32cde864d24b0dde2ba6b1f0ff4.png)


HTTPS抓包


从截图可以看出，这里面完整经历了TCP握手和TLS加密握手流程，之后就是两段加密信息和TCP挥手流程。


可以看出18号和20号包，一个是从端口56028发到443，一个是443到56028的回包。


一般来说，像56028这种比较大且没啥规律的数字，都是客户端随机生成的端口号。


而443，则是HTTPS的服务器端口号。


HTTP用的是80端口，如果此时对着80端口抓包，也会抓不到数据。


粗略判断，18号和20号包分别是客户端请求baidu.com的请求包和响应包。


点进去看会发现URL和body都被加密了，一无所获。


那么问题就来了。有没有办法解密里面的数据呢？


有办法。我们来看下怎么做。


### 解密数据包


还是先执行tcpdump抓包

$ tcpdump -i eth0 host 39.156.66.10 -w baidu.pcap

 然后在另外一个命令行窗口下执行下面的命令，目的是将加密的key导出，并给出对应的导出地址是/Users/xiaobaidebug/ssl.key。

$ export SSLKEYLOGFILE=/Users/xiaobaidebug/ssl.key

 然后在同一个命令行窗口下，继续执行curl命令或用命令行打开chrome浏览器。目的是为了让curl或chrome继承这个环境变量。

$ curl ‘https://baidu.com’
或者
$ open -a Google\ Chrome #在mac里打开chrome浏览器

此时会看到在/Users/xiaobaidebug/下会多了一个ssl.key文件。


这时候跟着下面的操作修改wireshark的配置项。


![图片](https://img-blog.csdnimg.cn/290615ee53d140858851a208c6848603.png)


打开wireshark的配置项


找到Protocols之后，使劲往下翻，找到TLS那一项。


![图片](https://img-blog.csdnimg.cn/e3499debe7c44482b47097edabb3150a.png)


在配置项中找到Protocols


将导出的ssl.key文件路径输入到这里头。


![图片](https://img-blog.csdnimg.cn/3e8f2506349a4bf6b9a03c4bc76301bc.png)


在Protocols中找到TLS那一栏


点击确定后，就能看到18号和20号数据包已经被解密。


![图片](https://img-blog.csdnimg.cn/18ea844d2ccf44818541d605a251b7bf.png)


解密后的数据包内容


此时再用http.host == “baidu.com”，就能过滤出数据了。


![图片](https://img-blog.csdnimg.cn/1945a17dbced4f82b69c280176db7288.png)



解密后的数据包中可以过滤出baidu的数据包


到这里，其实看不了数据包的问题就解决了。


但是，新的问题又来了。


ssl.key文件是个啥？


这就要从HTTPS的加密原理说起了。


### HTTPS握手过程


HTTPS的握手过程比较繁琐，我们来回顾下。


先是建立TCP连接，毕竟HTTP是基于TCP的应用层协议。


在TCP成功建立完协议后，就可以开始进入HTTPS阶段。


HTTPS可以用TLS或者SSL啥的进行加密，下面我们以TLS1.2为例。


总的来说。整个加密流程其实分为两阶段。


第一阶段是TLS四次握手，这一阶段主要是利用非对称加密的特性各种交换信息，最后得到一个"会话秘钥"。


第二阶段是则是在第一阶段的"会话秘钥"基础上，进行对称加密通信。


![图片](https://img-blog.csdnimg.cn/cfee9319c23e4758ae9a79ca7ab99883.png)


TLS四次握手


我们先来看下第一阶段的TLS四次握手是怎么样的。


**第一次握手：**


• Client Hello：是客户端告诉服务端，它支持什么样的加密协议版本，比如 TLS1.2，使用什么样的加密套件，比如最常见的RSA，同时还给出一个客户端随机数。


**第二次握手：**


• Server Hello：服务端告诉客户端，服务器随机数 + 服务器证书 + 确定的加密协议版本（比如就是TLS1.2）。


**第三次握手：**


• Client Key Exchange: 此时客户端再生成一个随机数，叫 pre\_master\_key 。从第二次握手的服务器证书里取出服务器公钥，用公钥加密 pre\_master\_key，发给服务器。


• Change Cipher Spec: 客户端这边已经拥有三个随机数：客户端随机数，服务器随机数和pre\_master\_key，用这三个随机数进行计算得到一个"会话秘钥"。此时客户端通知服务端，后面会用这个会话秘钥进行对称机密通信。


• Encrypted Handshake Message：客户端会把迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给服务器做校验，此时客户端这边的握手流程就结束了，因此也叫Finished报文。


**第四次握手：**


• Change Cipher Spec：服务端此时拿到客户端传来的 pre\_master\_key（虽然被服务器公钥加密过，但服务器有私钥，能解密获得原文），集齐三个随机数，跟客户端一样，用这三个随机数通过同样的算法获得一个"会话秘钥"。此时服务器告诉客户端，后面会用这个"会话秘钥"进行加密通信。


• Encrypted Handshake Message：跟客户端的操作一样，将迄今为止的通信数据内容生成一个摘要，用"会话秘钥"加密一下，发给客户端做校验，到这里，服务端的握手流程也结束了，因此这也叫Finished报文。


四次握手中，客户端和服务端最后都拥有三个随机数，他们很关键，我特地加粗了表示。


第一次握手，产生的客户端随机数，叫client random。


第二次握手时，服务器也会产生一个服务器随机数，叫server random。


第三次握手时，客户端还会产生一个随机数，叫pre\_master\_key。


这三个随机数共同构成最终的对称加密秘钥，也就是上面提到的"会话秘钥"。



![图片](https://img-blog.csdnimg.cn/11c695f31a1d4cbbb65ece3572a96f41.png)


三个随机数生成对称秘钥


你可以简单的认为，只要知道这三个随机数，你就能破解HTTPS通信。


而这三个随机数中，client random 和 server random 都是明文的，谁都能知道。而pre\_master\_key却不行，它被服务器的公钥加密过，只有客户端自己，和拥有对应服务器私钥的人能知道。


所以问题就变成了，怎么才能得到这个pre\_master\_key？


### 怎么得到pre\_master\_key


服务器私钥不是谁都能拿到的，所以问题就变成了，有没有办法从客户端那拿到这个pre\_master\_key。


有的。


客户端在使用HTTPS与服务端进行数据传输时，是需要先基于TCP建立HTTP连接，然后再调用客户端侧的TLS库（OpenSSL、NSS）。触发TLS四次握手。


这时候如果加入环境变量SSLKEYLOGFILE就可以干预TLS库的行为，让它输出一份含有pre\_master\_key的文件。这个文件就是我们上面提到的/Users/xiaobaidebug/ssl.key。




![img](https://img-blog.csdnimg.cn/img_convert/ff635a5cbd142adae3dbef3d95e5f6f9.png)
![img](https://img-blog.csdnimg.cn/img_convert/8f068b14f3f554cef5a17e65428597de.png)
![img](https://img-blog.csdnimg.cn/img_convert/2fefadbcb5fc07d03214cbe922446027.png)

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！**

。触发TLS四次握手。


这时候如果加入环境变量SSLKEYLOGFILE就可以干预TLS库的行为，让它输出一份含有pre\_master\_key的文件。这个文件就是我们上面提到的/Users/xiaobaidebug/ssl.key。




[外链图片转存中...(img-8pgrv6I5-1719249718675)]
[外链图片转存中...(img-DzCG62Rs-1719249718676)]
[外链图片转存中...(img-KY69FUaS-1719249718677)]

**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！**