为什么我抓不到Baidu的数据包 你会吗

最近，有位读者问起一个奇异的事情，他说他想抓一个baidu.com的数据包，体验下看包的乐趣。

但却发现“抓不到”，这就有些奇异了。

我来恢复下他的操作步骤。

首先，经过ping命令，取得访问百度时会恳求哪个IP。

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

于是用上方的tcpdump命令启动抓包，大略的意思是抓eth0网卡且ip为39.156.66.10的网络包，保留到baidu.pcap文件中。

此时在阅读器中关上baidu.com网页。或许在另外一个命令行窗口，间接用curl命令来模拟下。

按理说，访问baidu.com的数据包必需曾经抓上去了。

而后中止抓包。

再用wireshark关上baidu.pcap文件，在过滤那一栏里输入http.host == "baidu.com"。

此时发现，满载而归。

在wireshark中搜查baidu的包，发现满载而归

这是为啥？

到这里，有阅历的小同伴，其实曾经知道疑问出在哪里了。

为什么没能抓到包

这其实是由于他访问的是HTTPS协定的baidu.com。HTTP协定里的Host和实践发送的request body都会被加密。

正由于被加密了，所以没方法经过http.host启动过滤。

但是。

只管加密了，假构想挑选还是可以筛的。

HTTPS握手中的Client Hello阶段，外面有个裁减server_name，会记载你想访问的是哪个网站，经过上方的挑选条件可以将它过滤出来。

经过tls的裁减server_name可以搜查到baidu的包

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

右键找到tcp 流

这个TCP衔接的其余关系报文全都能被展现出来。

HTTPS抓包

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

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

普通来说，像56028这种比拟大且没啥法令的数字，都是客户端随机生成的端口号。

而443，则是HTTPS的主机端口号。

粗略判别，18号和20号包区分是客户端恳求baidu.com的恳求包和照应包。

点出来看会发现URL和body都被加密了，满载而归。

那么疑问就来了。有没有方法解密外面的数据呢？

有方法。咱们来看下怎样做。

解密数据包

还是先口头tcpdump抓包。

而后在另外一个命令行窗口下口头上方的命令，目标是将加密的key导出，并给出对应的导出地址是​ ​/Users/xiaobaidebug/ssl.key​ ​。

而后在同一个命令行窗口下，继续口头curl命令或用命令行关上chrome阅读器。 目标是为了让curl或chrome承袭这个环境变量。

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

这时刻跟着上方的操作修正wireshark的性能项。

关上wireshark的性能项

找到Protocols之后，用力往下翻，找到TLS那一项。

在性能项中找到Protocols

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

在Protocols中找到TLS那一栏

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

解密后的数据包内容

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

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

到这里，其实看不了数据包的疑问就处置了。

但是，新的疑问又来了。

ssl.key文件是个啥？

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

HTTPS握手环节

HTTPS的握手环节比拟繁琐，咱们来回忆下。

先是建设TCP衔接，毕竟HTTP是基于TCP的运行层协定。

在TCP成功建设完协定后，就可以开局进入HTTPS阶段。

HTTPS可以用TLS或许SSL啥的启动加密，上方咱们以​​为例。

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

第一阶段是TLS四次握手，这一阶段关键是应用非对称加密的特性各种替换信息，最后失掉一个"会话秘钥"。

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

TLS四次握手

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

第一次性握手：

第二次握手：

第三次握手：

第四次握手：

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

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

第二次握手时，主机也会发生一个主机随机数，叫server random。

第三次握手时，客户端还会发生一个随机数，叫pre_master_key。

这三个随机数独特造成最终的对称加密秘钥，也就是上方提到的"会话秘钥"。

三个随机数生成对称秘钥

你可以方便的以为，只需知道这三个随机数，你就能破解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。

将环境变量注入到curl和chrome中

但是，只管TLS库允许导出key文件。但前提也是，下层的运行程序在调用TLS库的时刻，允许经过SSLKEYLOGFILE环境触发TLS库导出文件。实践上，也并不是一切运行程序都允许将SSLKEYLOGFILE。只是目前经常出现的curl和chrome阅读器都是允许的。

SSLKEYLOGFILE文件内容

再回过头来看ssl.key文件里的内容。

这里有三列。

第一列是CLIENT_RANDOM，意思是接上去的第二列就是客户端随机数，再接上去的第三列则是pre_master_key。

但是疑问又来了。

这么多行，wireshark怎样知道用哪行的pre_master_key呢？

wireshark​是可以取得数据报文上的client random的。

比如下图这样。

Client Hello 里的客户端随机数

留意上方的客户端随机数是以"bff63bbe5"开头的。

雷同，还能在数据报文里拿到server random。

找到server random

此时将client random放到ssl.key的第二列里挨个去做婚配。

就能找到对应的那一行记载。

ssl.key里的数据

留意第二列的那串字符串，也是以"bff63bbe5"​开头的，它其实就是前面提到的client random。

再取出这一行的第三列数据，就是咱们想要的pre_master_key。

那么这时刻wireshark就集齐了三个随机数，此时就可以计算失掉会话秘钥，经过它对数据启动解密了。

反上来，正由于须要客户端随机数，能力定位到ssl.key​文件里对应的pre_master_key​是哪一个。而只要TLS第一次性握手（client hello）的时刻才会有这个随机数，所以假设你想用解密HTTPS包，就必需将TLS四次握手能抓齐，能力启动解密。假设衔接早曾经建设了，数据都来回传好半天了，这时刻你再去抓包，是没方法解密的。

总结