0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

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

小林coding ? 來源:小林coding ? 2023-01-05 10:43 ? 次閱讀

最近,有位讀者問起一個奇怪的事情,他說他想抓一個baidu.com的數(shù)據(jù)包,體驗下看包的樂趣。

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

我來還原下他的操作步驟。

首先,通過ping命令,獲得訪問百度時會請求哪個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é)果可以知道請求baidu.com時會去訪問39.156.66.10。

于是用下面的tcpdump命令進行抓包,大概的意思是抓eth0網(wǎng)卡且ip39.156.66.10網(wǎng)絡(luò)包,保存到baidu.pcap文件中。

$tcpdump-ieth0host39.156.66.10-wbaidu.pcap

此時在瀏覽器中打開baidu.com網(wǎng)頁。或者在另外一個命令行窗口,直接用curl命令來模擬下。

$curl'https://baidu.com'

按理說,訪問baidu.com的數(shù)據(jù)包肯定已經(jīng)抓下來了。

然后停止抓包。

再用wireshark打開baidu.pcap文件,在過濾那一欄里輸入http.host == "baidu.com"。

此時發(fā)現(xiàn),一無所獲。

fc284964-8c7f-11ed-bfe3-dac502259ad0.png在wireshark中搜索baidu的包,發(fā)現(xiàn)一無所獲

這是為啥?

到這里,有經(jīng)驗的小伙伴,其實已經(jīng)知道問題出在哪里了。

為什么沒能抓到包

這其實是因為他訪問的是HTTPS協(xié)議的baidu.com。HTTP協(xié)議里的Host和實際發(fā)送的request body都會被加密。

正因為被加密了,所以沒辦法通過http.host進行過濾。

但是。

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

HTTPS握手中的Client Hello階段,里面有個擴展server_name,會記錄你想訪問的是哪個網(wǎng)站,通過下面的篩選條件可以將它過濾出來。

tls.handshake.extensions_server_name=="baidu.com"
fc3140be-8c7f-11ed-bfe3-dac502259ad0.png通過tls的擴展server_name可以搜索到baidu的包

此時選中其中一個包,點擊右鍵,選中Follow-TCP Stream

fc3a9da8-8c7f-11ed-bfe3-dac502259ad0.png右鍵找到tcp 流

這個TCP連接的其他相關(guān)報文全都能被展示出來。

fc425098-8c7f-11ed-bfe3-dac502259ad0.pngHTTPS抓包

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

可以看出18號和20號包,一個是從端口56028發(fā)到443,一個是443到56028的回包。

一般來說,像56028這種比較大且沒啥規(guī)律的數(shù)字,都是客戶端隨機生成的端口號。

443,則是HTTPS的服務(wù)器端口號。

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

粗略判斷,18號和20號包分別是客戶端請求baidu.com的請求包和響應(yīng)包。

點進去看會發(fā)現(xiàn)URL和body都被加密了,一無所獲。

那么問題就來了。有沒有辦法解密里面的數(shù)據(jù)呢?

有辦法。我們來看下怎么做。

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

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

$tcpdump-ieth0host39.156.66.10-wbaidu.pcap

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

$exportSSLKEYLOGFILE=/Users/xiaobaidebug/ssl.key

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

$curl'https://baidu.com'
或者
$open-aGoogleChrome#在mac里打開chrome瀏覽器

此時會看到在/Users/xiaobaidebug/下會多了一個ssl.key文件。

這時候跟著下面的操作修改wireshark的配置項。

fc4b563e-8c7f-11ed-bfe3-dac502259ad0.png打開wireshark的配置項

找到Protocols之后,使勁往下翻,找到TLS那一項。

fc51eddc-8c7f-11ed-bfe3-dac502259ad0.png在配置項中找到Protocols

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

fc5f3848-8c7f-11ed-bfe3-dac502259ad0.png在Protocols中找到TLS那一欄

點擊確定后,就能看到18號和20號數(shù)據(jù)包已經(jīng)被解密。

fc68f04a-8c7f-11ed-bfe3-dac502259ad0.png解密后的數(shù)據(jù)包內(nèi)容

此時再用http.host == "baidu.com",就能過濾出數(shù)據(jù)了。

fc75dc2e-8c7f-11ed-bfe3-dac502259ad0.png解密后的數(shù)據(jù)包中可以過濾出baidu的數(shù)據(jù)包

到這里,其實看不了數(shù)據(jù)包的問題就解決了。

但是,新的問題又來了。

ssl.key文件是個啥?

這就要從HTTPS的加密原理說起了。

HTTPS握手過程

HTTPS的握手過程比較繁瑣,我們來回顧下。

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

在TCP成功建立完協(xié)議后,就可以開始進入HTTPS階段。

HTTPS可以用TLS或者SSL啥的進行加密,下面我們以TLS1.2為例。

總的來說。整個加密流程其實分為兩階段。

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

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

fc7fb9ba-8c7f-11ed-bfe3-dac502259ad0.pngTLS四次握手

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

第一次握手

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

第二次握手

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

第三次握手

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

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

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

第四次握手

  • ?Change Cipher Spec:服務(wù)端此時拿到客戶端傳來的pre_master_key(雖然被服務(wù)器公鑰加密過,但服務(wù)器有私鑰,能解密獲得原文),集齊三個隨機數(shù),跟客戶端一樣,用這三個隨機數(shù)通過同樣的算法獲得一個"會話秘鑰"。此時服務(wù)器告訴客戶端,后面會用這個"會話秘鑰"進行加密通信。

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

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

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

第二次握手時,服務(wù)器也會產(chǎn)生一個服務(wù)器隨機數(shù),叫server random。

第三次握手時,客戶端還會產(chǎn)生一個隨機數(shù),叫pre_master_key。

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

fc88ae3a-8c7f-11ed-bfe3-dac502259ad0.png三個隨機數(shù)生成對稱秘鑰

你可以簡單的認為,只要知道這三個隨機數(shù),你就能破解HTTPS通信。

而這三個隨機數(shù)中,client randomserver random都是明文的,誰都能知道。pre_master_key卻不行,它被服務(wù)器的公鑰加密過,只有客戶端自己,和擁有對應(yīng)服務(wù)器私鑰的人能知道。

所以問題就變成了,怎么才能得到這個pre_master_key

怎么得到pre_master_key

服務(wù)器私鑰不是誰都能拿到的,所以問題就變成了,有沒有辦法從客戶端那拿到這個pre_master_key。

有的。

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

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

fc8f1b12-8c7f-11ed-bfe3-dac502259ad0.png將環(huán)境變量注入到curl和chrome中

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

SSLKEYLOGFILE文件內(nèi)容

再回過頭來看ssl.key文件里的內(nèi)容。

#SSL/TLSsecretslogfile,generatedbyNSS
CLIENT_RANDOM5709aef8ba36a8eeac72bd6f970a74f7533172c52be41b200ca9b91354bd662b09d156a5e6c0d246549f6265e73bda72f0d6ee81032eaaa0bac9bea362090800174e0effc93b93c2ffa50cd8a715b0f0
CLIENT_RANDOM57d269386549a4cec7f91158d85ca1376a060ef5a6c2ace04658fe88aec4877648c16429d362bea157719da5641e2f3f13b0b3fee2695ef2b7cdc71c61958d22414e599c676ca96bbdb30eca49eb488a
CLIENT_RANDOM5fca0f2835cbb5e248d7b3e75180b2b3aff000929e33e5bacf5f5a4bff63bbe5424e1fcfff35e76d5bf88f21d6c361ee7a9d32cb8f2c60649135fd9b66d569d8c4add6c9d521e148c63977b7a95e8fe8
CLIENT_RANDOMbe610cb1053e6f3a01aa3b88bc9e8c77a708ae4b0f953b2063ca5f925d673140c26e3cf83513a830af3d3401241e1bc4fdda187f98ad5ef9e14cae71b0ddec85812a81d793d6ec934b9dcdefa84bdcf3

這里有三列。

第一列是CLIENT_RANDOM,意思是接下來的第二列就是客戶端隨機數(shù),再接下來的第三列則是pre_master_key

但是問題又來了。

這么多行,wireshark怎么知道用哪行的pre_master_key呢?

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

比如下圖這樣。

fc955e46-8c7f-11ed-bfe3-dac502259ad0.pngClient Hello 里的客戶端隨機數(shù)

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

同樣,還能在數(shù)據(jù)報文里拿到server random

fca0a1ac-8c7f-11ed-bfe3-dac502259ad0.png找到server random

此時將client random放到ssl.key的第二列里挨個去做匹配。

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

fcad0456-8c7f-11ed-bfe3-dac502259ad0.pngssl.key里的數(shù)據(jù)

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

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

那么這時候wireshark就集齊了三個隨機數(shù),此時就可以計算得到會話秘鑰,通過它對數(shù)據(jù)進行解密了。

反過來,正因為需要客戶端隨機數(shù),才能定位到ssl.key文件里對應(yīng)的pre_master_key是哪一個。而只有TLS第一次握手(client hello)的時候才會有這個隨機數(shù),所以如果你想用解密HTTPS包,就必須將TLS四次握手能抓齊,才能進行解密。如果連接早已經(jīng)建立了,數(shù)據(jù)都來回傳好半天了,這時候你再去抓包,是沒辦法解密的。

總結(jié)

  • ?文章開頭通過抓包baidu的數(shù)據(jù)包,展示了用wireshark抓包的簡單操作流程。

  • ?HTTPS會對HTTP的URL和Request Body都進行加密,因此直接在filter欄進行過濾http.host == "baidu.com"會一無所獲。

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

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

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

審核編輯 :李倩


聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 命令
    +關(guān)注

    關(guān)注

    5

    文章

    684

    瀏覽量

    22037
  • 數(shù)據(jù)包
    +關(guān)注

    關(guān)注

    0

    文章

    261

    瀏覽量

    24402

原文標題:好氣??!為什么我抓不到 baidu 的數(shù)據(jù)包?

文章出處:【微信號:小林coding,微信公眾號:小林coding】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    mtu配置步驟詳解 mtu與數(shù)據(jù)包丟失的關(guān)系

    MTU(Maximum Transmission Unit)即最大傳輸單元,是指一種通信協(xié)議的某一層上面所能通過的最大數(shù)據(jù)報大小,單位是字節(jié)。MTU配置步驟及其與數(shù)據(jù)包丟失的關(guān)系如下: MTU配置
    的頭像 發(fā)表于 12-16 14:33 ?582次閱讀

    CentOS中使用tcpdump

    CentOS中使用tcpdump
    的頭像 發(fā)表于 10-28 14:48 ?258次閱讀

    請問DCTCP與DCUDP 的登錄數(shù)據(jù)包和心跳數(shù)據(jù)包與服務(wù)器端是如何交互的?

    DCTCP與DCUDP的登錄數(shù)據(jù)包和心跳數(shù)據(jù)包與服務(wù)器端是如何交互的?
    發(fā)表于 07-25 06:37

    經(jīng)典藍牙解析說明

    在無線通信協(xié)議的開發(fā)過程中,器是工程師們不可或缺的工具。掌握器的使用,就如同擁有了能夠洞察無線電波的“火眼金睛”。這不僅使我們能夠驗證發(fā)出的
    的頭像 發(fā)表于 07-24 09:04 ?2010次閱讀
    經(jīng)典藍牙<b class='flag-5'>抓</b><b class='flag-5'>包</b>解析說明

    使用AT SAVETRANSLINK時UDP數(shù)據(jù)包丟失怎么解決?

    Android 發(fā)送一個小 UDP 數(shù)據(jù)包(5 字節(jié))。這個小數(shù)據(jù)包被我的微控制器在UART上接收到。微控制器將更大的數(shù)據(jù)包(可變長度,約 100 字節(jié))發(fā)送回 UART。ESP在UART上接
    發(fā)表于 07-18 07:17

    能否在ESP結(jié)束之前通過串行端口停止傳入的UDP數(shù)據(jù)包的傳輸以解析下一個UDP數(shù)據(jù)包?

    我正在做一個artnet節(jié)點, 它收到幾個 UDP 廣播數(shù)據(jù)包,工作正常,但是: 其中一些必須使用,其中一些必須丟棄, mi問題是:所有傳入的數(shù)據(jù)包都出現(xiàn)在帶有IPD命令的串行端口上, 并且我需要
    發(fā)表于 07-16 06:18

    請問如何使用AT CIPSEND或AT CIPSENDBUF發(fā)送多個數(shù)據(jù)包

    我可以使用 AT CIPSEND 發(fā)送單個數(shù)據(jù)包。但是我必須發(fā)送一系列二進制數(shù)據(jù)包。如何使用AT CISEND或AT CIPSENDBUF發(fā)送多個數(shù)據(jù)包,什么是正確的算法? 到目前為止,我嘗試
    發(fā)表于 07-15 07:37

    在AN65974中短數(shù)據(jù)包和零長數(shù)據(jù)包是什么意思?

    在 AN65974 中,短數(shù)據(jù)包和零長數(shù)據(jù)包是什么意思? 非常感謝!
    發(fā)表于 05-30 07:41

    如何在AIROC GUI上獲取良好數(shù)據(jù)包和總數(shù)據(jù)包

    使用 IQxel-MW LifePoint 作為發(fā)生器并發(fā)送波形BT_1DH5_00001111_Fs80M.iqvsg,但無法在 AIROC 工具中接收數(shù)據(jù)包。 以下是從 IQxel 發(fā)送
    發(fā)表于 05-22 06:39

    TSN包工具解密:數(shù)據(jù)包捕獲,為什么選Profishark?

    在網(wǎng)絡(luò)管理中,網(wǎng)絡(luò)流量分析和故障排查是重要環(huán)節(jié),如何高效精準地進行網(wǎng)絡(luò)流量分析和故障排查?來看看利用ProfiShark數(shù)據(jù)包捕獲,讓我們一起探索其中的優(yōu)勢和特點。一、捕獲網(wǎng)絡(luò)流量的重要性捕獲
    的頭像 發(fā)表于 04-29 08:04 ?599次閱讀
    TSN<b class='flag-5'>抓</b>包工具解密:<b class='flag-5'>數(shù)據(jù)包</b>捕獲,為什么選Profishark?

    請問高端網(wǎng)絡(luò)芯片如何處理數(shù)據(jù)包呢?

    隨著網(wǎng)絡(luò)芯片帶寬的持續(xù)提升,其內(nèi)部數(shù)據(jù)包處理單元的工作負載也隨之增加。然而,如果處理單元無法與網(wǎng)絡(luò)接口的傳入速率相匹配,將無法及時處理數(shù)據(jù)包,這不僅會導(dǎo)致數(shù)據(jù)包隨機丟失,更會降低網(wǎng)絡(luò)的吞吐量。
    的頭像 發(fā)表于 04-02 16:36 ?646次閱讀
    請問高端網(wǎng)絡(luò)芯片如何處理<b class='flag-5'>數(shù)據(jù)包</b>呢?

    STM32H7接收數(shù)據(jù)包異常,一接收的數(shù)據(jù)出現(xiàn)兩發(fā)送的內(nèi)容怎么解決?

    );__HAL_UART_DISABLE_IT( huart1, DMA_IT_HT); 2、發(fā)送數(shù)據(jù)包1
    發(fā)表于 03-08 08:05

    STM32H750如何提高數(shù)據(jù)包大???

    我使用STM32H750官方的VCP例程,F(xiàn)S模式。 程序默認CDC_DATA_FS_MAX_PACKET_SIZE是64位,我試著修改最大只能到256,如果再大會導(dǎo)致接收不到數(shù)據(jù)。芯片資料MPSIZ設(shè)置范圍可以到2047。 我想提高數(shù)
    發(fā)表于 03-07 06:12

    DPDK在AI驅(qū)動的高效數(shù)據(jù)包處理應(yīng)用

    傳統(tǒng)的數(shù)據(jù)包處理方式是數(shù)據(jù)包先到內(nèi)核最后再到用戶層進行處理。這種方式會增加額外的延遲和CPU開銷,嚴重影響數(shù)據(jù)包處理的性能。 DPDK 繞過內(nèi)核,在用戶空間中實現(xiàn)快速數(shù)據(jù)包處理。
    的頭像 發(fā)表于 02-25 11:28 ?953次閱讀
    DPDK在AI驅(qū)動的高效<b class='flag-5'>數(shù)據(jù)包</b>處理應(yīng)用

    使用P4和Vivado工具簡化數(shù)據(jù)包處理設(shè)計

    電子發(fā)燒友網(wǎng)站提供《使用P4和Vivado工具簡化數(shù)據(jù)包處理設(shè)計.pdf》資料免費下載
    發(fā)表于 01-26 17:49 ?0次下載
    使用P4和Vivado工具簡化<b class='flag-5'>數(shù)據(jù)包</b>處理設(shè)計