为什么我抓不到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，同时还给出一个客户端随机数。
　　第二次握手：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通信。
　　而这三个随机数中，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用于解密。附抓包教程
　　开始抓包
　　当你打开wireshark会出现网卡列表（如下图）通常可以先将网卡连接在要抓包设备的交换机上以捕获数据包，想要捕获哪个网卡的数据包直接双击就可以了，简单方便（这里使用老师的无线网卡进行演示）。
　　开始抓包后，因为网络中的数据量可能十分庞大，在捕获到我们想要的数据包之后，就可以点击左上角的停止捕获按钮让wireshark停止捕获，三个按钮依次为开始、停止、重新捕获。
　　接下来我们来看数据包列表
　　No代表序号
　　也就是第几个被捕获的数据包
　　time表示相对捕获时间
　　source代表的是数据包的源地址
　　destination表示数据包的目的地址
　　protocol是解析出数据包的协议类型
　　info是摘要的数据包信息
　　根据以上这些信息我们可以选择我们想要的数据包进行查看分析，这里我们选择一个http包进行举例
　　点开数据包后可以发现，上面有几个折叠的信息，越靠近上面的就越靠近物理层，越靠近下面的则越靠近应用层我们依次点开看看都能获取到哪些信息
　　首先展开看到的是物理层的信息，包括物理接口的相关信息，帧的长度，以及帧是不是被丢弃的状态。
　　接下来展开的是二层的信息，包括以太网帧的封装类型，这里是以太二，以及源mac地址和目标mac地址，由于wireshark是一个自带分析功能的抓包工具，它可以帮助标出相关有用的字段，比如图中就标出了mac地址是一个单播地址（mac地址的第8位为单播/组播位，置0为单播，置1为组播），这种功能在抓包的时候非常直观方便，当然也可以在下面的十六进制区自己找到相应的字段进行分析。
　　接下来是三层信息，包括了ip版本（ipv4）、头部长度、DS Field、头部校验和、以及我们通常第一眼回去看的源目ip地址和TTL字段。
　　再来是传输层信息，这里我们比较关注的信息主要有传输层的协议、源目端口、段的大小、序列号（seq Number）以及标志位信息、payload大小等。图中展示的包可以看出，传输层协议为TCP、源端口为80证明是一个http相关的包，tcp段长度为53bytes，以及标志位ACK置位（这里如果要找是谁的ack，可以将seq号减一进行查找，就知道这个ACK是对哪个数据包进行的回复）
　　接下来的上层协议作为网络工程师通常我们是不太关心的，但有时候有需求也可以打开分析一下，如这里我们看到http返回了一个200，我们就可以知道这个包是正常响应的包，关于上层应用的抓包在有些项目中我们需要做防火墙或者服务器的时候就可能会需要了，幸运的是wireshark对相关的功能也都是支持的。
　　那么基本的操作我们知道了，但是在复杂的网络环境中，想在这么多数据包中找到我们想要看到的数据包，有时候简直就像是大海捞针一样，那有没有什么方法可以快速的找到我们需要的数据包，或者是有哪些操作对我们的抓包分析有帮助呢？
　　03
　　Wireshark常用过滤方式
　　地址过滤：ip.addr 用于显示出符合相应ip地址的数据包，同时有ip.src和ip.dst用于更详细的指定是要源IP符合还是目的IP符合。同理eth.addr用于显示出符合相应mac地址的数据包，eth.src和eth.dst用于更详细的指定我们具体要的是源mac还是目的mac。
　　协议过滤：假如我们想抓一个特殊的端口，那么可以使用tcp.port或udp.port进行相关的过滤，如果想过滤某一种协议也可以直接输入协议名，如想过滤出ospf的报文，就可以直接在过滤器中输入ospf即可。
　　常用逻辑符号：and代表与，or代表或，not代表非，eq即equal可以理解为等号
　　了解了以上常用的一些过滤方式，接下来我们来试着练习一下，建议同学们也跟着动手操作，以便快速得掌握这项技能。
　　首先我们试着过滤出源ip为192.168.10.243，且目的mac为f8:48:fd:fc:2e:00的数据包
　　接下来，我们利用dns的端口号排除其中的dns报文
　　接下来我们添加上所有的广播报文
　　经过上面的练习，我们熟悉了对地址、协议、逻辑运算符的使用，接下来我们试着对网络内的报文按照一定的特征进行一次抓取
　　首先我们要从中过滤出ospf的包
　　然后我们要找到所有与二类lsa相关的报文
　　我们打开一个LSU报文可以看到其中是有二类LSA的才被过滤器留下，其余的报文则全部被过滤掉，方便我们更快的找到我们想要的数据包进行对比。
　　看完今天的分享相信一些小伙伴们已经跃跃欲试准备亲自动手试试看了，想知道wireshark还有哪些更有趣的用法吗，点赞收藏学网工不迷路，后续我们会继续分享更多知识干货。
　　最后
　　最近原创更文的阅读量稳步下跌，思前想后，夜里辗转反侧。