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

本文为社区首发签约文章，14天内禁止转载，14天后未获授权禁止转载，侵权必究！

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

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

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

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

$ ping baidu.com
PING baidu.com (39.156.66.10) 56(84) bytes of data.
64 bytes from 39.156.66.10 (39.156.66.10): icmp_seq=1 ttl=49 time=30.6 ms
64 bytes from 39.156.66.10 (39.156.66.10): icmp_seq=2 ttl=49 time=30.6 ms
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协议的baidu.com。HTTP协议里的Host和实际发送的request body都会被加密。

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

但是。

尽管加密了，假如想挑选还是能够筛的。

HTTPS握手中的Client Hello阶段，里边有个扩展server_name，会记载你想拜访的是哪个网站，经过下面的挑选条件能够将它过滤出来。

  tls.handshake.extensions_server_name == "baidu.com"

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

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

从截图能够看出，这儿面完好经历了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的装备项。

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

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

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

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

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

但是，新的问题又来了。

ssl.key文件是个啥？

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

HTTPS握手进程

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

先是树立TCP衔接，究竟HTTP是基于TCP的应用层协议。

在TCP成功树立完协议后，就能够开端进入HTTPS阶段。

HTTPS能够用TLS或许SSL啥的进行加密，下面咱们以TLS1.2为例。

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

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

第二阶段是则是在榜首阶段的”会话秘钥”基础上，进行对称加密通讯。

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

榜首次握手：

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

第2次握手：

• Server Hello：服务端告知客户端，服务器随机数 + 服务器证书 + 确认的加密协议版别（比方便是TLS1.2）。

第三次握手：

• Client Key Exchange: 此刻客户端再生成一个随机数，叫 pre_master_key 。从第2次握手的服务器证书里取出服务器公钥，用公钥加密 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。

第2次握手时，服务器也会发生一个服务器随机数，叫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。

但是，尽管TLS库支撑导出key文件。但前提也是，上层的应用程序在调用TLS库的时候，支撑经过SSLKEYLOGFILE环境触发TLS库导出文件。实际上，也并不是所有应用程序都支撑将SSLKEYLOGFILE。仅仅现在常见的curl和chrome浏览器都是支撑的。

SSLKEYLOGFILE文件内容

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

# SSL/TLS secrets log file, generated by NSS
CLIENT_RANDOM 5709aef8ba36a8eeac72bd6f970a74f7533172c52be41b200ca9b91354bd662b 09d156a5e6c0d246549f6265e73bda72f0d6ee81032eaaa0bac9bea362090800174e0effc93b93c2ffa50cd8a715b0f0
CLIENT_RANDOM 57d269386549a4cec7f91158d85ca1376a060ef5a6c2ace04658fe88aec48776 48c16429d362bea157719da5641e2f3f13b0b3fee2695ef2b7cdc71c61958d22414e599c676ca96bbdb30eca49eb488a
CLIENT_RANDOM 5fca0f2835cbb5e248d7b3e75180b2b3aff000929e33e5bacf5f5a4bff63bbe5 424e1fcfff35e76d5bf88f21d6c361ee7a9d32cb8f2c60649135fd9b66d569d8c4add6c9d521e148c63977b7a95e8fe8
CLIENT_RANDOM be610cb1053e6f3a01aa3b88bc9e8c77a708ae4b0f953b2063ca5f925d673140 c26e3cf83513a830af3d3401241e1bc4fdda187f98ad5ef9e14cae71b0ddec85812a81d793d6ec934b9dcdefa84bdcf3

这儿有三列。

榜首列是CLIENT_RANDOM，意思是接下来的第二列便是客户端随机数，再接下来的第三列则是pre_master_key。

但是问题又来了。

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

wireshark是能够取得数据报文上的client random的。

比方下图这样。

留意上面的客户端随机数是以 "bff63bbe5"结束的。

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

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

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

留意第二列的那串字符串，也是以 "bff63bbe5"结束的，它其实便是前面说到的client random。

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

那么这时候wireshark就集齐了三个随机数，此刻就能够计算得到会话秘钥，经过它对数据进行解密了。

反过来，正因为需求客户端随机数，才干定位到ssl.key文件里对应的pre_master_key是哪一个。而只有TLS榜首次握手（client hello）的时候才会有这个随机数，所以假如你想用解密HTTPS包，就必须将TLS四次握手能抓齐，才干进行解密。假如衔接早现已树立了，数据都来回传好半天了，这时候你再去抓包，是没方法解密的。

总结

• 文章开头经过抓包baidu的数据包，展现了用wireshark抓包的简单操作流程。
• HTTPS会对HTTP的URL和Request Body都进行加密，因而直接在filter栏进行过滤http.host == "baidu.com"会一无所得。
• HTTPS握手的进程中会先经过非对称秘要去交换各种信息，其中就包含3个随机数，再经过这三个随机数去生成对称秘要的会话秘钥，后续运用这个会话秘钥去进行对称加密通讯。假如能取得这三个随机数就能解密HTTPS的加密数据包。
• 三个随机数，分别是客户端随机数（client random），服务端随机数（server random）以及pre_master_key。前两个，是明文，第三个是被服务器公钥加密过的，在客户端侧需求经过SSLKEYLOGFILE去导出。
• 经过设置SSLKEYLOGFILE环境变量，再让curl或chrome会恳求HTTPS域名，会让它们在调用TLS库的一同导出对应的sslkey文件。这个文件里包含了三列，其中最重要的是第二列的client random信息以及第三列的pre_master_key。第二列client random用于定位，第三列pre_master_key用于解密。

参考资料

极客时刻 -《网络排查案例课》

最终

最近原创更文的阅读量稳步下跌，思前想后，夜里辗转反侧。

我有个不成熟的恳求。

脱离广东好长时刻了，良久没人叫我靓仔了。

大家能够在谈论区里，叫我一靓仔吗？

我这么善良质朴的愿望，能被满意吗？

假如实在叫不出口的话，能帮我点下关注和右下角的点赞+在看吗？

别说了，一同在常识的海洋里呛水吧