在 Day 16 與 Day 17 中，我們利用 Wireshark 的「追蹤 TCP 串流 (Follow TCP Stream)」功能，輕而易舉地把隱藏在 GET 網址與 POST 表單中的帳號密碼給扒了出來。

這兩天的實戰應該讓你深刻體會到：只要沒有加密，封包在網路上就是裸奔。

為了修補這個致命缺陷，現代網際網路全面推行了 HTTPS (HyperText Transfer Protocol Secure)。它在原本的 HTTP 應用層與 TCP 傳輸層之間，插入了一個極其強大的保鑣——TLS (傳輸層安全性協定)。今天，我們將對 HTTPS 流量使用同一招「追蹤 TCP 串流」，讓你親眼見證密碼學的威力！

一、製造並捕捉 HTTPS 流量 (TLS 交握)

當我們在瀏覽器輸入 https:// 開頭的網址時，雙方在傳送真正的網頁資料前，會先進行一場名為「TLS Handshake (交握)」的加密協議過程。

【實作練習】

1. 開啟 Wireshark，套用 tls 顯示過濾器並開始擷取。
2. 打開終端機，輸入帶有 https 的指令：

   curl https://httpbin.org/get
   

畫面解析：
從 Wireshark 的列表中，你可以看到雙方不再是一上來就發送 HTTP GET 請求。取而代之的是 Client Hello (客戶端打招呼並提議加密演算法)、Server Hello (伺服器回應並確認加密方式)，以及 Certificate (伺服器出示數位憑證)。直到雙方喬好密碼本後，才會開始傳送真正的資料。

二、尋找加密後的「應用層資料」

交握完成後，真正的 HTTP 請求與回應去哪裡了？它們穿上了防彈衣。

【實作練習】
停止抓包後，我們在封包列表中往下找，點擊一個 Info 欄位標示為 Application Data 的封包。接著在中間的詳細資訊窗格，展開 Transport Layer Security 這一層。

畫面解析：
以前我們在這個位置，可以直接展開 HTTP 看到 Method、URI 或是表單參數。但現在，Wireshark 只能無奈地顯示這是一包 Encrypted Application Data (已加密的應用程式資料)。不管裡面藏的是帳號密碼還是信用卡號，對於任何攔截到封包的第三方來說，它就只是一團毫無意義的位元組。

三、殺手鐧失效？見證亂碼的威力

最後，我們來試試看用前兩天無往不利的殺手鐧，對付這團加密資料。

【實作練習】
對著剛剛那個 Application Data 封包按 「右鍵」，選擇 「Follow (追蹤)」 -> 「TCP Stream (TCP 串流)」。

畫面解析：
點開對話視窗後，結果令人無比安心！除了最開頭在進行交握時，有幾段未加密的憑證資訊（例如網域 httpbin.org）還勉強能認出英文字母外，雙方真正傳遞的資料已經全部變成了毫無邏輯的亂碼、問號與奇怪的點點。

這就是現代網路安全的基石。只要伺服器正確實作了 HTTPS，就算駭客與你處在同一個區域網路，甚至用 Wireshark 攔截了你所有的封包，也絕對無法得知你傳送了什麼機密內容。

🎯 今日小結

今天我們將矛頭轉向了 HTTPS，透過實際的封包攔截與串流追蹤，對比了 HTTP 的脆弱與 TLS 加密的強大。這也是為什麼現在各大瀏覽器（如 Chrome、Edge）只要看到未加密的 HTTP 網站，都會直接在網址列標示「不安全」的根本原因。

🔜 明日預告

我們已經學會了如何看透單一連線的內容。但如果今天伺服器遭到駭客攻擊，瞬間湧入幾萬個封包，我們該如何快速找出「誰是攻擊者」？
明天 [Day 19]，我們將暫時放下單一封包的微觀視角，帶你運用 Wireshark 強大的**「統計 (Statistics) 工具」與「端點分析 (Endpoints)」**，用上帝視角找出網路中的可疑流量！我們明天見。