從wireshake分析http和https的通信過程

參考文章:

• Wireshark基本介紹和學習TCP三次握手
• 【技術流】Wireshark對HTTPS數據的解密
• Wireshark/HTTPS
• Journey to HTTP/2
• 以TCP/IP協議為例，如何通過wireshark抓包分析？
• TCP三次握手和四次揮手
• Https詳解+wireshark抓包演示

前言

面試被問到有沒有用過抓包工具, 還真沒有... 彌補一波. 一直以來看http和https的介紹, 都是文章, 然后圖片, 理解的也不深入. 借此一個機會, 深入理解下.

入行不久, 寫的哪里不對的, 請諒解. 還望各位路過的大佬幫忙指出, 十分感謝.

軟件使用

軟件使用分析

我剛開始用, 哪里不對的. 望大神們見諒.

操作步驟

在官網中有很舒服的操作原理說明: Wireshark/HTTPS

1. 安裝Wireshark
2. 裝個瀏覽器就行了
3. 點擊開始捕獲, 右上角, 鯊魚標志
4. 在瀏覽器中輸入http://www.cnblogs.com/zhangrunhao/
5. 或者是https
6. 頁面渲染完成后, 點擊停止捕獲
7. 在篩選欄中輸入http, 看到一個info是GET /zhangrunhao/ HTTP/1.1
8. 記錄下請求的ip. (注: 當你找不到ip的時候, 不要慌, 嘗試 ping <域名>即可, 例如: ping www.cnblogs.com)
9. 篩選欄中改為ip.addr == <記錄下的ip地址>
10. 大概你就可以看到你想要的了.

大概了解tcp字段

具體的tcp協議的講解, 可以參考TCP協議

tcp協議中的各個字段.
這篇文章中需要用到的三個字段:

• sequence number: 序列號

  占4個字節，是本報文段所發送的數據項目組第一個字節的序號。在TCP傳送的數據流中，每一個字節都有一個序號。例如，一報文段的序號為300，而且數據共100字節，則下一個報文段的序號就是400；序號是32bit的無符號數，序號到達2^32-1后從0開始.

• Acknowledgment number: 確認碼

  占4字節, 是期望收到對方下次發送的數據的第一個字節的序號, 也就是期望收到的下一個報文段的首部中的序號. 確認序號應該是上次已成功收到數據字節序號+1. 只有ACK標志為1時, 確認序號才有效.

• Flag: 標志位.(共用6個標志位, 我們只看需要用的幾個.)

  • ACK：只有當ACK=1時，確認序號字段才有效
  • SYN：SYN=1,ACK=0時表示請求建立一個連接，攜帶SYN標志的TCP報文段為同步報文段.
  • FIN：發端完成發送任務。

  

HTTP協議中TCP握手過程

三次握手的簡單建立過程: 所有的TCP鏈接都是通過三次握手開始的, 也就是客戶端和服務器在發送應用數據之前, 發送一系列的數據包.

一次完整的三次握手的過程就完成了, 客戶端和服務器端的數據就可以開始傳輸了. 需要注意的是, 客戶端一旦發送完最后一個ACK數據包, 就立即開始發送應用數據, 但是服務器端需要等到最后一個ACK包接受完成才會去響應請求.

抓包看三次握手

• 第一次握手:

  
  客戶端向服務器發出請求建立的鏈接, 標志為是SYN, 這個時候報文中的同部位SYN=1, 然后我們的序列號也回生成好, seq=x. 這個時候, 三次握手也就開始了.

• 第二次握手:

  
  服務器收到請求, 並發送給客戶端確認報文. 在確認的報文中, 標志位應該為ACK SYN, 因為此時還沒有攜帶數據, 所以這個時候, ack = seq(x, 客戶端發送過來的那個) + 1, 並在這條報文中初始化序列號, seq = y. 發送給客戶端, 讓客戶端用來確認, 我們第二次握手的請求建立過程. 詢問下客戶端是否准備完成了.

• 第三次握手:

  
  客戶端收到服務器發送過來的第二次握手的tcp請求, 再次向服務器發送確認. 只是確認的時候, 標志為只需要是ACK, 同時生成確認序號: ack = y(這里的y, 是服務器第二次握手發送過來的seq) + 1. 這里表示客戶端, 已經准備好了.

• 題外話: 為什么是三次握手, 而不是兩次?

  因為在我們第一次客戶端發送握手請求的時候, 會出現網絡情況不好, 發了很久才給服務器. 服務器收到請求后, 就會發送確認收到. 后面就會一直傻傻等待客戶端傳數據過來, 其實不知道, 這條請求鏈接在客戶端那邊已經作廢了. 從而造成資源的浪費.

抓包看四次揮手

在實際的捕獲中, 只抓到三個tcp的數據包, 有資料講解, 服務器給客戶端確認關閉, 並向客戶端發起關閉請求的的鏈接合並成了一個. 也就是第二和第三次揮手, 都是由服務器端發送給客戶端的, 這個時候合並成了一個請求.

• 第一次揮手:

  

  第一次揮手的過程, 是客戶端向服務器端發起請求. 發送一個帶有FIN ACK標志位tcp包. 我們可以看到這個時候seq = 1; ack = 1. 表示, 凡是帶有FIN標志位的tcp包, 都是為了告訴另一端, 我再沒有數據需要傳遞給你了.

• 第二次揮手和第三次揮手:

  

  本來, 第二次揮手是, 服務器用來確認客戶端發送過來的請求的.然后再告訴客戶端, 服務器也沒什么好給你的東西了. 我理解的, 這應該是一種資源的優化, 既然都是服務器發送給客戶端, 如果再服務器確認之后, 確實也沒有要發送的了, 就直接一起發送過去了.變成了seq=1, ack=2. 標志位是FIN ACK, 其中ack = 2表示確認第一次揮手.

• 第四次揮手:

  

  這是我們的最后一次揮手過程, 由客戶端向服務器發送確認過程. 標志位ACK, 表示, 這是一個用於確認的tcp包. 發送ack(確認二三次揮手seq + 1) = 2. 至此一次完整的http通信過程就全部完成了.

• 那么問題來了: 為什么是四次揮手, 而不是三次呢?

  因為, 在揮手的過程中, 第一次揮手的時候, 客戶端發送向了服務器端不需要通信的請求. 服務器端通過第二次揮手確認了收到. 但並不能保證, 服務器端再沒有需要給客戶端發送的信息了啊. 只是表明了, 客戶端沒有要發送給服務器的數據了, 服務器知道了. 但是服務器沒有需要給客戶端的數據, 就需要通過第三次揮手來表示. 客戶端回復收到. 至此才算完完全全的完成.

HTTPS中的TCP交互過程

一句話概況: 通過非對稱加密的方式來傳遞對稱加密所需要的秘鑰.

我懶, 還是貼圖好了(原諒我這名盜圖狗), 等會我們在抓包的過程中逐步分析.

注意一點: ssl / tls的交互過程, 是在完成我們上面的三次握手開始的.

具體的抓包分析

此過程完全參考了Wireshark中關於HTTPS的操作說明.

步驟1: 捕獲HTTPS

1. 打開一個新的瀏覽器窗口或者tab頁.
2. 開始捕獲.
3. 瀏覽器導航到https://en.wikiversity.org.
4. 停止捕獲.
5. 關閉瀏覽器窗口或者tab頁.

步驟2: 確定你要捕獲的那個流量通道

1. 在Wireshark最上面的列表中觀察捕獲到的鏈接列表. 為了只觀察HTTPS的請求, 在篩選欄中輸入ssl, 然后回車.
2. 選擇第一個帶有Client Hello標志的TLS包.
3. 觀察IP地址.
4. 為了觀察所有這個鏈接的tcp請求, 在篩選框中輸入ip.addr == <destination> destination是指, 我們的ip地址.

說兩個事:

• 為什么篩選ssl, 出現大量的tsl? tsl是以建立在sslV3.0的基礎上, 兩者的加密算法和MAC算法都不一樣, 而協議本身差異性不大.
• 我還是感覺, 命令行, 直接ping域名, 找ip, 比較方便哎~ ping en.wikiversity.org 多么舒服的做法..

步驟3: 分析tcp數據包

1. 觀察數據包列表, 看到最上面的三次握手. 也就是帶有(SYN, SYN ACK, ACK)標志位的數據包.
2. 在中間的數據框中, 觀察數據包的詳細信息. 這里包含了, 物理層, 網絡層, 傳輸層的詳細信息.
3. 展開 Ethernet II, 查看以太網, 數據鏈路層的詳細信息.
4. 我們可以看到本機和服務器的MAC地址.你可以使用ipconfig /all和arp -a進行確認
5. 展開Internet Protocol Version 4這一層, 查看網絡層的詳情.
6. 你可以看到你的ip地址, 和服務器的ip地址.
7. 展開Transmission Control Protocol, 你可以看到傳輸層的詳細信息.
8. 你可以看到本機提供的端口號, 和服務器的端口號(443).
9. 注意: 所有的tcp數據包, 都含有匹配的MAC地址, ip地址, 端口號.

步驟4: 分析SSL/TLSClient Hello數據包

1. 雙擊打開, 帶有Client Hello標識的tsl數據包. 這里還有, 物理層, 鏈路層, 網絡層, 傳輸層, 安全傳輸層的信息, 這里和步驟三中的各項數據保持一致.
2. 展開安全傳輸層, TLS和握手協議, 去查看SSL/TLS中的詳細數據.
3. 可以觀察到客戶端支持的各種加密方式.
4. 觀察下一個帶有TCP ACK標識的tcp數據包, 那是服務器端對於收到客戶端請求的回應.

步驟5: 分析SSL/TLSServer Hello數據包

1. 雙擊打開, 帶有Server Hello標識的數據包.
2. 依照我們上面的經驗, 應該清楚我們要觀察Secure Sockets Layer, 也就數安全數據層.
3. 這個時候, 服務器端返回了他所支持的加密方式, 是客戶端所傳遞的一個子集. 肯定要兩邊都行的嘛.

步驟6: 分析SSL/TLS 交換證書的階段

1. 雙擊, 打開帶有Certificate, Server Key Exchange, Server Hello Done.標識的數據包.
2. 展開Secure Sockets Layer, 讓我們來仔細觀察安全層所攜帶的數據.
3. 我們可以看到這一次tcp上面, tsl的數據包含了三塊: 分別是: 證書, 非對稱加密的公鑰(Server Key), 還有一個服務器信息結束標識.
4. 我們可以看到證書提供的信息.
5. 我們還可以看到我們的公鑰信息!.
6. 客戶端使用證書來驗證公鑰和簽名. 這些工作瀏覽器會幫助我們進行處理.

步驟7: 客戶端的秘鑰交換

1. 雙擊打開, 帶有Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message標識的tcp數據包.
2. 這一次的交互中, 客戶端使用公鑰對將對稱加密的秘鑰進行加密, 並發送給了服務器.
3. 從抓包上來看: 具體過程應該是, 客戶端的秘鑰交換, 然后更改加密規范, 然后對與握手的信息進行了加密.(對於, tls層的操作還需要深入理解, 再次不再深究. 有希望繼續學習的小伙伴, 留個言, 我們一起搞起來)
4. 

步驟8: 開始數據交互

• 后面就是帶有Application Data的數據之間的傳遞了, 此時的數據都是經過加密的.
• 留個疑問, 有些交互過程帶有New Session Ticket.標識的數據包, 服務器用來確定加密信息, 有些不帶有, 還不是很清楚的具體原因. 有待學習, 有待學習.

總結

不會的地方可真多... 文章若有錯誤的地方, 還望大家能夠幫忙指出. 大恩不言謝, 他日以身相許.