为什么我抓不到baidu的数据包_互联网资讯__分享互联网新鲜有趣好玩的事物-云易优站长平台

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

比来，有位读者问起一个奇异的工作，他说他想抓一个baidu.com的数据包，体验下看包的乐趣。

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

我来复原下他的操做步调。

起首，通过ping号令，获得拜候百度时会恳求哪个IP。

$ ping baidu.comPING 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 ms64 bytes from 39.156.66.10 (39.156.66.10): icmp_seq=2 ttl=49 time=30.6 ms64 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"复造代码为什么我抓不到baidu的数据包第3张

此时选中此中一个包，点击右键，选中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 NSSCLIENT_RANDOM 5709aef8ba36a8eeac72bd6f970a74f7533172c52be41b200ca9b91354bd662b 09d156a5e6c0d246549f6265e73bda72f0d6ee81032eaaa0bac9bea362090800174e0effc93b93c2ffa50cd8a715b0f0CLIENT_RANDOM 57d269386549a4cec7f91158d85ca1376a060ef5a6c2ace04658fe88aec48776 48c16429d362bea157719da5641e2f3f13b0b3fee2695ef2b7cDC71c61958d22414e599c676ca96bbdb30eca49eb488aCLIENT_RANDOM 5fca0f2835cbb5e248d7b3e75180b2b3aff000929e33e5bacf5f5a4bff63bbe5 424e1fcfff35e76d5bf88f21d6c361ee7a9d32cb8f2c60649135fd9b66d569d8c4add6c9d521e148c63977b7a95e8fe8CLIENT_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是对哪个数据包停止的回复）