從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層的操做還須要深刻理解, 再次再也不深究. 有但願繼續學習的小夥伴, 留個言, 咱們一塊兒搞起來)

步驟8: 開始數據交互

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

總結

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