為什么抓不到baidu的數(shù)據(jù)包？

最近，有位讀者問(wèn)起一個(gè)奇怪的事情，他說(shuō)他想抓一個(gè)复制baidu.com的數(shù)據(jù)包，體驗(yàn)下看包的樂(lè)趣。

但卻發(fā)現(xiàn)“抓不到”，這就有些奇怪了。

我來(lái)還原下他的操作步驟。

首先，通過(guò)复制ping命令，獲得訪問(wèn)百度時(shí)會(huì)請(qǐng)求哪個(gè)IP。

复制$pingbaidu.com
PINGbaidu.com(39.156.66.10)56(84)bytesofdata.
64bytesfrom39.156.66.10(39.156.66.10):icmp_seq=1ttl=49time=30.6ms
64bytesfrom39.156.66.10(39.156.66.10):icmp_seq=2ttl=49time=30.6ms
64bytesfrom39.156.66.10(39.156.66.10):icmp_seq=3ttl=49time=30.6ms

從上面的結(jié)果可以知道請(qǐng)求复制baidu.com時(shí)會(huì)去訪問(wèn)复制39.156.66.10。

于是用下面的复制tcpdump命令進(jìn)行抓包，大概的意思是抓复制eth0網(wǎng)卡且复制ip為复制39.156.66.10的網(wǎng)絡(luò)包，保存到复制baidu.pcap文件中。

复制$tcpdump-ieth0host39.156.66.10-wbaidu.pcap

此時(shí)在瀏覽器中打開(kāi)复制baidu.com網(wǎng)頁(yè)?；蛘咴诹硗庖粋€(gè)命令行窗口，直接用复制curl命令來(lái)模擬下。

复制$curl'https://baidu.com'

按理說(shuō)，訪問(wèn)baidu.com的數(shù)據(jù)包肯定已經(jīng)抓下來(lái)了。

然后停止抓包。

再用复制wireshark打開(kāi)复制baidu.pcap文件，在過(guò)濾那一欄里輸入复制http.host == "baidu.com"。

此時(shí)發(fā)現(xiàn)，一無(wú)所獲。

在wireshark中搜索baidu的包，發(fā)現(xiàn)一無(wú)所獲

這是為啥？

到這里，有經(jīng)驗(yàn)的小伙伴，其實(shí)已經(jīng)知道問(wèn)題出在哪里了。

為什么沒(méi)能抓到包

這其實(shí)是因?yàn)樗L問(wèn)的是HTTPS協(xié)議的baidu.com。HTTP協(xié)議里的Host和實(shí)際發(fā)送的request body都會(huì)被加密。

正因?yàn)楸患用芰?，所以沒(méi)辦法通過(guò)复制http.host進(jìn)行過(guò)濾。

但是。

雖然加密了，如果想篩選還是可以篩的。

HTTPS握手中的Client Hello階段，里面有個(gè)擴(kuò)展复制server_name，會(huì)記錄你想訪問(wèn)的是哪個(gè)網(wǎng)站，通過(guò)下面的篩選條件可以將它過(guò)濾出來(lái)。

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

通過(guò)tls的擴(kuò)展server_name可以搜索到baidu的包

此時(shí)選中其中一個(gè)包，點(diǎn)擊右鍵，選中复制Follow-TCP Stream。

右鍵找到tcp 流

這個(gè)TCP連接的其他相關(guān)報(bào)文全都能被展示出來(lái)。

HTTPS抓包

從截圖可以看出，這里面完整經(jīng)歷了TCP握手和TLS加密握手流程，之后就是兩段加密信息和TCP揮手流程。

可以看出18號(hào)和20號(hào)包，一個(gè)是從端口56028發(fā)到443，一個(gè)是443到56028的回包。

一般來(lái)說(shuō)，像复制56028這種比較大且沒(méi)啥規(guī)律的數(shù)字，都是客戶端隨機(jī)生成的端口號(hào)。

而复制443，則是HTTPS的服務(wù)器端口號(hào)。

HTTP用的是80端口，如果此時(shí)對(duì)著80端口抓包，也會(huì)抓不到數(shù)據(jù)。

粗略判斷，18號(hào)和20號(hào)包分別是客戶端請(qǐng)求复制baidu.com的請(qǐng)求包和響應(yīng)包。

點(diǎn)進(jìn)去看會(huì)發(fā)現(xiàn)URL和body都被加密了，一無(wú)所獲。

那么問(wèn)題就來(lái)了。有沒(méi)有辦法解密里面的數(shù)據(jù)呢？

有辦法。我們來(lái)看下怎么做。

解密數(shù)據(jù)包

還是先執(zhí)行tcpdump抓包

复制$tcpdump-ieth0host39.156.66.10-wbaidu.pcap

然后在另外一個(gè)命令行窗口下執(zhí)行下面的命令，目的是將加密的key導(dǎo)出，并給出對(duì)應(yīng)的導(dǎo)出地址是复制/Users/xiaobaidebug/ssl.key。

复制$exportSSLKEYLOGFILE=/Users/xiaobaidebug/ssl.key

然后在同一個(gè)命令行窗口下，繼續(xù)執(zhí)行curl命令或用命令行打開(kāi)chrome瀏覽器。目的是為了讓curl或chrome繼承這個(gè)環(huán)境變量。

复制$curl'https://baidu.com'
或者
$open-aGoogleChrome#在mac里打開(kāi)chrome瀏覽器

此時(shí)會(huì)看到在复制/Users/xiaobaidebug/下會(huì)多了一個(gè)复制ssl.key文件。

這時(shí)候跟著下面的操作修改复制wireshark的配置項(xiàng)。

打開(kāi)wireshark的配置項(xiàng)

找到Protocols之后，使勁往下翻，找到复制TLS那一項(xiàng)。

在配置項(xiàng)中找到Protocols

將導(dǎo)出的复制ssl.key文件路徑輸入到這里頭。

在Protocols中找到TLS那一欄

點(diǎn)擊確定后，就能看到18號(hào)和20號(hào)數(shù)據(jù)包已經(jīng)被解密。

解密后的數(shù)據(jù)包內(nèi)容

此時(shí)再用复制http.host == "baidu.com"，就能過(guò)濾出數(shù)據(jù)了。

解密后的數(shù)據(jù)包中可以過(guò)濾出baidu的數(shù)據(jù)包

到這里，其實(shí)看不了數(shù)據(jù)包的問(wèn)題就解決了。

但是，新的問(wèn)題又來(lái)了。

ssl.key文件是個(gè)啥？

這就要從HTTPS的加密原理說(shuō)起了。

HTTPS握手過(guò)程

HTTPS的握手過(guò)程比較繁瑣，我們來(lái)回顧下。

先是建立TCP連接，畢竟HTTP是基于TCP的應(yīng)用層協(xié)議。

在TCP成功建立完協(xié)議后，就可以開(kāi)始進(jìn)入HTTPS階段。

HTTPS可以用TLS或者SSL啥的進(jìn)行加密，下面我們以复制TLS1.2為例。

總的來(lái)說(shuō)。整個(gè)加密流程其實(shí)分為兩階段。

第一階段是TLS四次握手，這一階段主要是利用非對(duì)稱加密的特性各種交換信息，最后得到一個(gè)"會(huì)話秘鑰"。

第二階段是則是在第一階段的"會(huì)話秘鑰"基礎(chǔ)上，進(jìn)行對(duì)稱加密通信。

TLS四次握手

我們先來(lái)看下第一階段的TLS四次握手是怎么樣的。

第一次握手：

• ?复制Client Hello：是客戶端告訴服務(wù)端，它支持什么樣的加密協(xié)議版本，比如复制TLS1.2，使用什么樣的加密套件，比如最常見(jiàn)的复制RSA，同時(shí)還給出一個(gè)客戶端隨機(jī)數(shù)。

第二次握手：

• ?复制Server Hello：服務(wù)端告訴客戶端，服務(wù)器隨機(jī)數(shù)+ 服務(wù)器證書 + 確定的加密協(xié)議版本（比如就是TLS1.2）。

第三次握手：

• ?复制Client Key Exchange: 此時(shí)客戶端再生成一個(gè)隨機(jī)數(shù)，叫复制pre_master_key。從第二次握手的服務(wù)器證書里取出服務(wù)器公鑰，用公鑰加密复制pre_master_key，發(fā)給服務(wù)器。

• ?复制Change Cipher Spec: 客戶端這邊已經(jīng)擁有三個(gè)隨機(jī)數(shù)：客戶端隨機(jī)數(shù)，服務(wù)器隨機(jī)數(shù)和pre_master_key，用這三個(gè)隨機(jī)數(shù)進(jìn)行計(jì)算得到一個(gè)"會(huì)話秘鑰"。此時(shí)客戶端通知服務(wù)端，后面會(huì)用這個(gè)會(huì)話秘鑰進(jìn)行對(duì)稱機(jī)密通信。

• ?复制Encrypted Handshake Message：客戶端會(huì)把迄今為止的通信數(shù)據(jù)內(nèi)容生成一個(gè)摘要，用"會(huì)話秘鑰"加密一下，發(fā)給服務(wù)器做校驗(yàn)，此時(shí)客戶端這邊的握手流程就結(jié)束了，因此也叫Finished報(bào)文。

第四次握手：

• ?复制Change Cipher Spec：服務(wù)端此時(shí)拿到客戶端傳來(lái)的复制pre_master_key（雖然被服務(wù)器公鑰加密過(guò)，但服務(wù)器有私鑰，能解密獲得原文），集齊三個(gè)隨機(jī)數(shù)，跟客戶端一樣，用這三個(gè)隨機(jī)數(shù)通過(guò)同樣的算法獲得一個(gè)"會(huì)話秘鑰"。此時(shí)服務(wù)器告訴客戶端，后面會(huì)用這個(gè)"會(huì)話秘鑰"進(jìn)行加密通信。

• ?复制Encrypted Handshake Message：跟客戶端的操作一樣，將迄今為止的通信數(shù)據(jù)內(nèi)容生成一個(gè)摘要，用"會(huì)話秘鑰"加密一下，發(fā)給客戶端做校驗(yàn)，到這里，服務(wù)端的握手流程也結(jié)束了，因此這也叫Finished報(bào)文。

四次握手中，客戶端和服務(wù)端最后都擁有三個(gè)隨機(jī)數(shù)，他們很關(guān)鍵，我特地加粗了表示。

第一次握手，產(chǎn)生的客戶端隨機(jī)數(shù)，叫复制client random。

第二次握手時(shí)，服務(wù)器也會(huì)產(chǎn)生一個(gè)服務(wù)器隨機(jī)數(shù)，叫复制server random。

第三次握手時(shí)，客戶端還會(huì)產(chǎn)生一個(gè)隨機(jī)數(shù)，叫复制pre_master_key。

這三個(gè)隨機(jī)數(shù)共同構(gòu)成最終的對(duì)稱加密秘鑰，也就是上面提到的"會(huì)話秘鑰"。

三個(gè)隨機(jī)數(shù)生成對(duì)稱秘鑰

你可以簡(jiǎn)單的認(rèn)為，只要知道這三個(gè)隨機(jī)數(shù)，你就能破解HTTPS通信。

而這三個(gè)隨機(jī)數(shù)中，复制client random和复制server random都是明文的，誰(shuí)都能知道。而复制pre_master_key卻不行，它被服務(wù)器的公鑰加密過(guò)，只有客戶端自己，和擁有對(duì)應(yīng)服務(wù)器私鑰的人能知道。

所以問(wèn)題就變成了，怎么才能得到這個(gè)复制pre_master_key？

怎么得到pre_master_key

服務(wù)器私鑰不是誰(shuí)都能拿到的，所以問(wèn)題就變成了，有沒(méi)有辦法從客戶端那拿到這個(gè)复制pre_master_key。

有的。

客戶端在使用HTTPS與服務(wù)端進(jìn)行數(shù)據(jù)傳輸時(shí)，是需要先基于TCP建立HTTP連接，然后再調(diào)用客戶端側(cè)的TLS庫(kù)（OpenSSL、NSS）。觸發(fā)TLS四次握手。

這時(shí)候如果加入環(huán)境變量SSLKEYLOGFILE就可以干預(yù)TLS庫(kù)的行為，讓它輸出一份含有复制pre_master_key的文件。這個(gè)文件就是我們上面提到的复制/Users/xiaobaidebug/ssl.key。

將環(huán)境變量注入到curl和chrome中

但是，雖然TLS庫(kù)支持導(dǎo)出key文件。但前提也是，上層的應(yīng)用程序在調(diào)用TLS庫(kù)的時(shí)候，支持通過(guò)复制SSLKEYLOGFILE環(huán)境觸發(fā)TLS庫(kù)導(dǎo)出文件。實(shí)際上，也并不是所有應(yīng)用程序都支持將SSLKEYLOGFILE。只是目前常見(jiàn)的curl和chrome瀏覽器都是支持的。

SSLKEYLOGFILE文件內(nèi)容

再回過(guò)頭來(lái)看复制ssl.key文件里的內(nèi)容。

复制#SSL/TLSsecretslogfile,generatedbyNSS
CLIENT_RANDOM5709aef8ba36a8eeac72bd6f970a74f7533172c52be41b200ca9b91354bd662b09d156a5e6c0d246549f6265e73bda72f0d6ee81032eaaa0bac9bea362090800174e0effc93b93c2ffa50cd8a715b0f0
CLIENT_RANDOM57d269386549a4cec7f91158d85ca1376a060ef5a6c2ace04658fe88aec4877648c16429d362bea157719da5641e2f3f13b0b3fee2695ef2b7cdc71c61958d22414e599c676ca96bbdb30eca49eb488a
CLIENT_RANDOM5fca0f2835cbb5e248d7b3e75180b2b3aff000929e33e5bacf5f5a4bff63bbe5424e1fcfff35e76d5bf88f21d6c361ee7a9d32cb8f2c60649135fd9b66d569d8c4add6c9d521e148c63977b7a95e8fe8
CLIENT_RANDOMbe610cb1053e6f3a01aa3b88bc9e8c77a708ae4b0f953b2063ca5f925d673140c26e3cf83513a830af3d3401241e1bc4fdda187f98ad5ef9e14cae71b0ddec85812a81d793d6ec934b9dcdefa84bdcf3

這里有三列。

第一列是CLIENT_RANDOM，意思是接下來(lái)的第二列就是客戶端隨機(jī)數(shù)，再接下來(lái)的第三列則是复制pre_master_key。

但是問(wèn)題又來(lái)了。

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

复制wireshark是可以獲得數(shù)據(jù)報(bào)文上的复制client random的。

比如下圖這樣。

Client Hello 里的客戶端隨機(jī)數(shù)

注意上面的客戶端隨機(jī)數(shù)是以复制"bff63bbe5"結(jié)尾的。

同樣，還能在數(shù)據(jù)報(bào)文里拿到server random。

找到server random

此時(shí)將复制client random放到ssl.key的第二列里挨個(gè)去做匹配。

就能找到對(duì)應(yīng)的那一行記錄。

ssl.key里的數(shù)據(jù)

注意第二列的那串字符串，也是以复制"bff63bbe5"結(jié)尾的，它其實(shí)就是前面提到的复制client random。

再取出這一行的第三列數(shù)據(jù)，就是我們想要的复制pre_master_key。

那么這時(shí)候复制wireshark就集齊了三個(gè)隨機(jī)數(shù)，此時(shí)就可以計(jì)算得到會(huì)話秘鑰，通過(guò)它對(duì)數(shù)據(jù)進(jìn)行解密了。

反過(guò)來(lái)，正因?yàn)樾枰蛻舳穗S機(jī)數(shù)，才能定位到复制ssl.key文件里對(duì)應(yīng)的复制pre_master_key是哪一個(gè)。而只有TLS第一次握手（复制client hello）的時(shí)候才會(huì)有這個(gè)隨機(jī)數(shù)，所以如果你想用解密HTTPS包，就必須將TLS四次握手能抓齊，才能進(jìn)行解密。如果連接早已經(jīng)建立了，數(shù)據(jù)都來(lái)回傳好半天了，這時(shí)候你再去抓包，是沒(méi)辦法解密的。

總結(jié)

• ?文章開(kāi)頭通過(guò)抓包baidu的數(shù)據(jù)包，展示了用wireshark抓包的簡(jiǎn)單操作流程。

• ?HTTPS會(huì)對(duì)HTTP的URL和Request Body都進(jìn)行加密，因此直接在复制filter欄進(jìn)行過(guò)濾复制http.host == "baidu.com"會(huì)一無(wú)所獲。

• ? HTTPS握手的過(guò)程中會(huì)先通過(guò)非對(duì)稱機(jī)密去交換各種信息，其中就包括3個(gè)隨機(jī)數(shù)，再通過(guò)這三個(gè)隨機(jī)數(shù)去生成對(duì)稱機(jī)密的會(huì)話秘鑰，后續(xù)使用這個(gè)會(huì)話秘鑰去進(jìn)行對(duì)稱加密通信。如果能獲得這三個(gè)隨機(jī)數(shù)就能解密HTTPS的加密數(shù)據(jù)包。

• ?三個(gè)隨機(jī)數(shù)，分別是客戶端隨機(jī)數(shù)（client random），服務(wù)端隨機(jī)數(shù)（server random）以及pre_master_key。前兩個(gè)，是明文，第三個(gè)是被服務(wù)器公鑰加密過(guò)的，在客戶端側(cè)需要通過(guò)SSLKEYLOGFILE去導(dǎo)出。

• ?通過(guò)設(shè)置SSLKEYLOGFILE環(huán)境變量，再讓curl或chrome會(huì)請(qǐng)求HTTPS域名，會(huì)讓它們?cè)谡{(diào)用TLS庫(kù)的同時(shí)導(dǎo)出對(duì)應(yīng)的sslkey文件。這個(gè)文件里包含了三列，其中最重要的是第二列的client random信息以及第三列的pre_master_key。第二列client random用于定位，第三列pre_master_key用于解密。

審核編輯 ：李倩