本文为掘金社区首发签约文章,14天内禁止转载,14天后未获授权禁止转载,侵权必究! 最近,有位读者问起一个奇怪的事情,他说他想抓一个baidu。com的数据包,体验下看包的乐趣。 但却发现抓不到,这就有些奇怪了。 我来还原下他的操作步骤。 首先,通过ping命令,获得访问百度时会请求哪个IP。pingbaidu。comPINGbaidu。com(39。156。66。10)56(84)bytesofdata。64bytesfrom39。156。66。10(39。156。66。10):icmpseq1ttl49time30。6ms64bytesfrom39。156。66。10(39。156。66。10):icmpseq2ttl49time30。6ms64bytesfrom39。156。66。10(39。156。66。10):icmpseq3ttl49time30。6ms复制代码 从上面的结果可以知道请求baidu。com时会去访问39。156。66。10。 于是用下面的tcpdump命令进行抓包,大概的意思是抓eth0网卡且ip为39。156。66。10的网络包,保存到baidu。pcap文件中。tcpdumpieth0host39。156。66。10wbaidu。pcap复制代码 此时在浏览器中打开baidu。com网页。或者在另外一个命令行窗口,直接用curl命令来模拟下。curlhttps:baidu。com复制代码 按理说,访问baidu。com的数据包肯定已经抓下来了。 然后停止抓包。 再用wireshark打开baidu。pcap文件,在过滤那一栏里输入http。hostbaidu。com。 此时发现,一无所获。 这是为啥? 到这里,有经验的小伙伴,其实已经知道问题出在哪里了。 为什么没能抓到包 这其实是因为他访问的是HTTPS协议的baidu。com。HTTP协议里的Host和实际发送的requestbody都会被加密。 正因为被加密了,所以没办法通过http。host进行过滤。 但是。 虽然加密了,如果想筛选还是可以筛的。 HTTPS握手中的ClientHello阶段,里面有个扩展servername,会记录你想访问的是哪个网站,通过下面的筛选条件可以将它过滤出来。tls。handshake。extensionsservernamebaidu。com复制代码 此时选中其中一个包,点击右键,选中FollowTCPStream。 这个TCP连接的其他相关报文全都能被展示出来。 从截图可以看出,这里面完整经历了TCP握手和TLS加密握手流程,之后就是两段加密信息和TCP挥手流程。 可以看出18号和20号包,一个是从端口56028发到443,一个是443到56028的回包。 一般来说,像56028这种比较大且没啥规律的数字,都是客户端随机生成的端口号。 而443,则是HTTPS的服务器端口号。 HTTP用的是80端口,如果此时对着80端口抓包,也会抓不到数据。 粗略判断,18号和20号包分别是客户端请求baidu。com的请求包和响应包。 点进去看会发现URL和body都被加密了,一无所获。 那么问题就来了。有没有办法解密里面的数据呢? 有办法。我们来看下怎么做。解密数据包 还是先执行tcpdump抓包tcpdumpieth0host39。156。66。10wbaidu。pcap复制代码 然后在另外一个命令行窗口下执行下面的命令,目的是将加密的key导出,并给出对应的导出地址是Usersxiaobaidebugssl。key。exportSSLKEYLOGFILEUsersxiaobaidebugssl。key复制代码 然后在同一个命令行窗口下,继续执行curl命令或用命令行打开chrome浏览器。目的是为了让curl或chrome继承这个环境变量。curlhttps:baidu。com或者openaGoogleChrome在mac里打开chrome浏览器复制代码 此时会看到在Usersxiaobaidebug下会多了一个ssl。key文件。 这时候跟着下面的操作修改wireshark的配置项。 找到Protocols之后,使劲往下翻,找到TLS那一项。 将导出的ssl。key文件路径输入到这里头。 点击确定后,就能看到18号和20号数据包已经被解密。 此时再用http。hostbaidu。com,就能过滤出数据了。 到这里,其实看不了数据包的问题就解决了。 但是,新的问题又来了。 ssl。key文件是个啥? 这就要从HTTPS的加密原理说起了。HTTPS握手过程 HTTPS的握手过程比较繁琐,我们来回顾下。 先是建立TCP连接,毕竟HTTP是基于TCP的应用层协议。 在TCP成功建立完协议后,就可以开始进入HTTPS阶段。 HTTPS可以用TLS或者SSL啥的进行加密,下面我们以TLS1。2为例。 总的来说。整个加密流程其实分为两阶段。 第一阶段是TLS四次握手,这一阶段主要是利用非对称加密的特性各种交换信息,最后得到一个会话秘钥。 第二阶段是则是在第一阶段的会话秘钥基础上,进行对称加密通信。 我们先来看下第一阶段的TLS四次握手是怎么样的。 第一次握手:ClientHello:是客户端告诉服务端,它支持什么样的加密协议版本,比如TLS1。2,使用什么样的加密套件,比如最常见的RSA,同时还给出一个客户端随机数。 第二次握手:ServerHello:服务端告诉客户端,服务器随机数服务器证书确定的加密协议版本(比如就是TLS1。2)。 第三次握手:ClientKeyExchange:此时客户端再生成一个随机数,叫premasterkey。从第二次握手的服务器证书里取出服务器公钥,用公钥加密premasterkey,发给服务器。ChangeCipherSpec:客户端这边已经拥有三个随机数:客户端随机数,服务器随机数和premasterkey,用这三个随机数进行计算得到一个会话秘钥。此时客户端通知服务端,后面会用这个会话秘钥进行对称机密通信。EncryptedHandshakeMessage:客户端会把迄今为止的通信数据内容生成一个摘要,用会话秘钥加密一下,发给服务器做校验,此时客户端这边的握手流程就结束了,因此也叫Finished报文。 第四次握手:ChangeCipherSpec:服务端此时拿到客户端传来的premasterkey(虽然被服务器公钥加密过,但服务器有私钥,能解密获得原文),集齐三个随机数,跟客户端一样,用这三个随机数通过同样的算法获得一个会话秘钥。此时服务器告诉客户端,后面会用这个会话秘钥进行加密通信。EncryptedHandshakeMessage:跟客户端的操作一样,将迄今为止的通信数据内容生成一个摘要,用会话秘钥加密一下,发给客户端做校验,到这里,服务端的握手流程也结束了,因此这也叫Finished报文。 四次握手中,客户端和服务端最后都拥有三个随机数,他们很关键,我特地加粗了表示。 第一次握手,产生的客户端随机数,叫clientrandom。 第二次握手时,服务器也会产生一个服务器随机数,叫serverrandom。 第三次握手时,客户端还会产生一个随机数,叫premasterkey。 这三个随机数共同构成最终的对称加密秘钥,也就是上面提到的会话秘钥。 你可以简单的认为,只要知道这三个随机数,你就能破解HTTPS通信。 而这三个随机数中,clientrandom和serverrandom都是明文的,谁都能知道。而premasterkey却不行,它被服务器的公钥加密过,只有客户端自己,和拥有对应服务器私钥的人能知道。 所以问题就变成了,怎么才能得到这个premasterkey?怎么得到premasterkey 服务器私钥不是谁都能拿到的,所以问题就变成了,有没有办法从客户端那拿到这个premasterkey。 有的。 客户端在使用HTTPS与服务端进行数据传输时,是需要先基于TCP建立HTTP连接,然后再调用客户端侧的TLS库(OpenSSL、NSS)。触发TLS四次握手。 这时候如果加入环境变量SSLKEYLOGFILE就可以干预TLS库的行为,让它输出一份含有premasterkey的文件。这个文件就是我们上面提到的Usersxiaobaidebugssl。key。 但是,虽然TLS库支持导出key文件。但前提也是,上层的应用程序在调用TLS库的时候,支持通过SSLKEYLOGFILE环境触发TLS库导出文件。实际上,也并不是所有应用程序都支持将SSLKEYLOGFILE。只是目前常见的curl和chrome浏览器都是支持的。SSLKEYLOGFILE文件内容 再回过头来看ssl。key文件里的内容。SSLTLSsecretslogfile,generatedbyNSSCLIENTRANDOM5709aef8ba36a8eeac72bd6f970a74f7533172c52be41b200ca9b91354bd662b09d156a5e6c0d246549f6265e73bda72f0d6ee81032eaaa0bac9bea362090800174e0effc93b93c2ffa50cd8a715b0f0CLIENTRANDOM57d269386549a4cec7f91158d85ca1376a060ef5a6c2ace04658fe88aec4877648c16429d362bea157719da5641e2f3f13b0b3fee2695ef2b7cdc71c61958d22414e599c676ca96bbdb30eca49eb488aCLIENTRANDOM5fca0f2835cbb5e248d7b3e75180b2b3aff000929e33e5bacf5f5a4bff63bbe5424e1fcfff35e76d5bf88f21d6c361ee7a9d32cb8f2c60649135fd9b66d569d8c4add6c9d521e148c63977b7a95e8fe8CLIENTRANDOMbe610cb1053e6f3a01aa3b88bc9e8c77a708ae4b0f953b2063ca5f925d673140c26e3cf83513a830af3d3401241e1bc4fdda187f98ad5ef9e14cae71b0ddec85812a81d793d6ec934b9dcdefa84bdcf3复制代码 这里有三列。 第一列是CLIENTRANDOM,意思是接下来的第二列就是客户端随机数,再接下来的第三列则是premasterkey。 但是问题又来了。 这么多行,wireshark怎么知道用哪行的premasterkey呢? wireshark是可以获得数据报文上的clientrandom的。 比如下图这样。 注意上面的客户端随机数是以bff63bbe5结尾的。 同样,还能在数据报文里拿到serverrandom。 此时将clientrandom放到ssl。key的第二列里挨个去做匹配。 就能找到对应的那一行记录。 注意第二列的那串字符串,也是以bff63bbe5结尾的,它其实就是前面提到的clientrandom。 再取出这一行的第三列数据,就是我们想要的premasterkey。 那么这时候wireshark就集齐了三个随机数,此时就可以计算得到会话秘钥,通过它对数据进行解密了。 反过来,正因为需要客户端随机数,才能定位到ssl。key文件里对应的premasterkey是哪一个。而只有TLS第一次握手(clienthello)的时候才会有这个随机数,所以如果你想用解密HTTPS包,就必须将TLS四次握手能抓齐,才能进行解密。如果连接早已经建立了,数据都来回传好半天了,这时候你再去抓包,是没办法解密的。总结文章开头通过抓包baidu的数据包,展示了用wireshark抓包的简单操作流程。HTTPS会对HTTP的URL和RequestBody都进行加密,因此直接在filter栏进行过滤http。hostbaidu。com会一无所获。HTTPS握手的过程中会先通过非对称机密去交换各种信息,其中就包括3个随机数,再通过这三个随机数去生成对称机密的会话秘钥,后续使用这个会话秘钥去进行对称加密通信。如果能获得这三个随机数就能解密HTTPS的加密数据包。三个随机数,分别是客户端随机数(clientrandom),服务端随机数(serverrandom)以及premasterkey。前两个,是明文,第三个是被服务器公钥加密过的,在客户端侧需要通过SSLKEYLOGFILE去导出。通过设置SSLKEYLOGFILE环境变量,再让curl或chrome会请求HTTPS域名,会让它们在调用TLS库的同时导出对应的sslkey文件。这个文件里包含了三列,其中最重要的是第二列的clientrandom信息以及第三列的premasterkey。第二列clientrandom用于定位,第三列premasterkey用于解密。附抓包教程 开始抓包 当你打开wireshark会出现网卡列表(如下图)通常可以先将网卡连接在要抓包设备的交换机上以捕获数据包,想要捕获哪个网卡的数据包直接双击就可以了,简单方便(这里使用老师的无线网卡进行演示)。 开始抓包后,因为网络中的数据量可能十分庞大,在捕获到我们想要的数据包之后,就可以点击左上角的停止捕获按钮让wireshark停止捕获,三个按钮依次为开始、停止、重新捕获。 接下来我们来看数据包列表 No代表序号 也就是第几个被捕获的数据包 time表示相对捕获时间 source代表的是数据包的源地址 destination表示数据包的目的地址 protocol是解析出数据包的协议类型 info是摘要的数据包信息 根据以上这些信息我们可以选择我们想要的数据包进行查看分析,这里我们选择一个http包进行举例 点开数据包后可以发现,上面有几个折叠的信息,越靠近上面的就越靠近物理层,越靠近下面的则越靠近应用层我们依次点开看看都能获取到哪些信息 首先展开看到的是物理层的信息,包括物理接口的相关信息,帧的长度,以及帧是不是被丢弃的状态。 接下来展开的是二层的信息,包括以太网帧的封装类型,这里是以太二,以及源mac地址和目标mac地址,由于wireshark是一个自带分析功能的抓包工具,它可以帮助标出相关有用的字段,比如图中就标出了mac地址是一个单播地址(mac地址的第8位为单播组播位,置0为单播,置1为组播),这种功能在抓包的时候非常直观方便,当然也可以在下面的十六进制区自己找到相应的字段进行分析。 接下来是三层信息,包括了ip版本(ipv4)、头部长度、DSField、头部校验和、以及我们通常第一眼回去看的源目ip地址和TTL字段。 再来是传输层信息,这里我们比较关注的信息主要有传输层的协议、源目端口、段的大小、序列号(seqNumber)以及标志位信息、payload大小等。图中展示的包可以看出,传输层协议为TCP、源端口为80证明是一个http相关的包,tcp段长度为53bytes,以及标志位ACK置位(这里如果要找是谁的ack,可以将seq号减一进行查找,就知道这个ACK是对哪个数据包进行的回复) 接下来的上层协议作为网络工程师通常我们是不太关心的,但有时候有需求也可以打开分析一下,如这里我们看到http返回了一个200,我们就可以知道这个包是正常响应的包,关于上层应用的抓包在有些项目中我们需要做防火墙或者服务器的时候就可能会需要了,幸运的是wireshark对相关的功能也都是支持的。 那么基本的操作我们知道了,但是在复杂的网络环境中,想在这么多数据包中找到我们想要看到的数据包,有时候简直就像是大海捞针一样,那有没有什么方法可以快速的找到我们需要的数据包,或者是有哪些操作对我们的抓包分析有帮助呢? 03hrWireshark常用过滤方式 地址过滤: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还有哪些更有趣的用法吗,点赞收藏学网工不迷路,后续我们会继续分享更多知识干货。 最后 最近原创更文的阅读量稳步下跌,思前想后,夜里辗转反侧。