Wireshark 抓包了解 HTTPS 協定

HTTPS 簡介

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer）協定是 HTTP 協定的安全版，在 HTTP 應用層和傳輸層加入了 SSL/TLS 層，確定資料傳輸的安全性，是以 HTTPS 協定并不是什麼新的協定，僅僅是 HTTP 協定和安全協定的組合。

HTTPS 協定主要解決如下三個通信安全問題：

竊聽風險（eavesdropping）：第三方可以獲知通信内容。
篡改風險（tampering）：第三方可以修改通信内容。
冒充風險（pretending）：第三方可以冒充他人身份參與通信。

HTTPS 通過 SSL/TLS 協定解決了上述三個問題，可以達到：

加密資料以防止資料中途被竊取；
維護資料的完整性，確定資料在傳輸過程中不被改變；
認證使用者和伺服器，確定資料發送到正确的客戶機和伺服器；

既然安全問題是 SSL/TLS 保證的，那麼就有必要仔細探索下 SSL/TLS 協定的機制，如下為 HTTPS 通信的整個網絡協定棧，其中 SSL/TLS 協定又分為兩層：

握手協定（SSL Handshake Protocol）：它建立在記錄協定之上，用于在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。
記錄協定（SSL Record Protocol）：它建立在可靠的傳輸協定（如TCP）之上，為高層協定提供資料封裝、壓縮、加密等基本功能的支援。

關于更多 SSL 和 TLS 知識見之前的文章: 基于 OpenSSL 生成自簽名證書。

Wireshark 抓包了解 HTTPS 協定

SSL/TLS 通信過程

開始加密通信之前，用戶端和伺服器首先必須建立連接配接和交換參數，這個過程叫做握手（handshake）。SSL/TLS 握手其實就是通過非對稱加密，生成對稱加密的 session key 的過程。

假定用戶端叫做愛麗絲伺服器叫做鮑勃，整個握手過程可以用下圖說明：

Wireshark 抓包了解 HTTPS 協定

整個握手過程通俗地說分為如下五步（真實的過程涉及的細節比這個多）：

第一步，愛麗絲給出協定版本号、一個用戶端生成的随機數（Client random），以及用戶端支援的加密方法。
第二步，鮑勃确認雙方使用的加密方法，并給出數字證書、以及一個伺服器生成的随機數（Server random）。
第三步，愛麗絲确認數字證書有效，然後生成一個新的随機數（Premaster secret），并使用數字證書中的公鑰，加密這個随機數，發給鮑勃。
第四步，鮑勃使用自己的私鑰，擷取愛麗絲發來的随機數（即Premaster secret）。
第五步，愛麗絲和鮑勃根據約定的加密方法，使用前面的三個随機數，生成"對話密鑰"（session key），用來加密接下來的整個對話過程。

Wireshark 抓包了解 HTTPS 協定

SSL 握手的過程為雙方發送消息的過程，這裡所說的消息并不是一個獨立的 TCP 資料包，而是 SSL 協定的術語。根據服務端實作的不同，可能一個 TCP 包中包含多條消息，而不是每條消息單獨發送（每條單獨發送效率太低），這個我們後面通過 Wireshark 抓包可以看到。

下圖為雙方握手過程中互相發送的 SSL 消息：

Wireshark 抓包了解 HTTPS 協定

用戶端發送的初始消息

Client Hello 消息

用戶端發送 Client Hello 消息給服務端來初始化會話消息，該消息包含如下資訊：

Version Number: 用戶端發送它所支援的最高 SSL/TLS 版本。版本 2 代表 SSL 2.0，版本 3 代表 SSL 3.0，版本 3.1 代表 TLS。
Randomly Generated Data：一個 32 位元組的用戶端随機數，該随機數被服務端生成通信用的對稱密鑰（master secret）；
Session Identification ：session ID 被用戶端用于恢複之前的會話（隻有恢複 session 時該字段才有值），這樣可以簡化 SSL 握手過程，避免每次請求都建立新的連接配接而握手，握手過程是需要消耗很多計算資源的。已建立的連接配接資訊存儲在用戶端和服務端各自的 session 緩存中，用 session ID 辨別；
Cipher Suite: 用戶端發送它所支援的加密套件清單；
Compression Algorithm: 壓縮算法，目前該字段幾乎不在使用；

服務端響應

Server Hello 消息

服務端回複 Server Hello 消息給用戶端：

Version Number：服務端發送雙發所支援的最高的 SSL/TLS 版本；
Randomly Generated Data：一個 32 位元組的服務端随機數，被用戶端用于生成通信用的對稱密鑰（master secret）；
Session Identification：該字段有如下三中情況：
New session ID：用戶端和服務端初次建立連接配接時生成的 session ID。或者用戶端嘗試恢複 session，但是服務端無法恢複，是以也會生成新的 session ID；
Resumed Session ID：和用戶端發送的恢複會話 ID 一緻，用于恢複會話；
Null：該字段為 Null，表明這是一個新的 Session，但是服務端不打算用于後續的會話恢複，是以不會産生 session ID，該字段為空；
Cipher Suite: 服務端發送雙發支援的最安全的加密套件；
Compression Algorithm：指定雙方使用的壓縮算法，目前該字段幾乎不在使用；

Server Certificate 消息

服務端發送自己的 SSL 證書給用戶端，證書中包含服務端的公鑰，用戶端用該證書驗證服務端的身份。

Server Key Exchange 消息

這個消息是可選的，該消息主要用來傳遞雙方協商密鑰的參數，比如雙方使用 Diffie-Hellman (迪菲) 算法生成 premaster secret 時，會用該字段傳遞雙方的公共參數。是以具體該字段是什麼内容取決于雙方協商密鑰的加密套件。

Client Certificate Request 消息

這個消息也是可選的，隻有當服務端也需要驗證用戶端會用到。有的安全度高的網站會要求驗證用戶端，确認客戶的真實身份，比如銀行之類的網站。

Server Hello Done 消息

伺服器發送 ServerHelloDone 消息，告知用戶端服務端這邊握手相關的消息發送完畢，等待用戶端響應。

用戶端回複

Client Certificate 消息

如果服務端發送了 Client Certificate Request 消息，那麼用戶端會發送該消息給服務端，包含自己的證書資訊，供服務端進行用戶端身份認證。

Client Key Exchange 消息

根據協商的密鑰算法不同，該消息的内容會不同，該消息主要包含密鑰協商的參數。比如雙方使用 Diffie-Hellman (迪菲) 算法生成 premaster secret 時，會用該字段傳遞雙方的公共參數。

Certificate Verify 消息

該消息隻有在 Client Certificate message 消息發送時才發送。用戶端通過自己的私鑰簽名從開始到現在的所有發送過的消息，然後服務端會用用戶端的公鑰驗證這個簽名。

Change Cipher Spec 消息

通知伺服器此消息以後用戶端會以之前協商的密鑰加密發送資料。

Client Finished 消息

用戶端計算生成對稱密鑰，然後使用該對稱密鑰加密之前所有收發握手消息的 Hash 值，發送給伺服器，伺服器将用相同的會話密鑰（使用相同方法生成）解密此消息，校驗其中的Hash 值。該消息是 SSL 握手協定記錄層加密的第一條消息。

服務端最後對用戶端響應

Change Cipher Spec 消息

通知用戶端此消息以後服務端将會以之前協商的密鑰加密發送資料。

Server Finished 消息

伺服器使用對稱密鑰加密（生成方式與用戶端相同）之前所發送的所有握手消息的hash值，發送給用戶端去校驗。

至此 SSL 握手過程結束，雙發之後的通信資料都會用雙方協商的對稱密鑰 Session Key 加密傳輸。

下圖為 SSL/TLS 通信的整個過程：TCP 三次握手 + SSL/TLS 握手：

Wireshark 抓包了解 HTTPS 協定

Wireshark 抓包分析 SSL/TLS 握手過程

本節使用 wireshark 抓包工具分析一個完整的 HTTPS 通信過程，看看通信過程中雙方消息是如何傳送的。前面我們說過，根據服務端實作的不同，可能一個 TCP 包中包含多條 SSL/TLS 消息，而不是每條消息單獨發送（每條單獨發送效率太低）。

使用如下 wireshark https 包過濾器:

tcp.port==443 and (ip.dst==104.18.40.252 or ip.src==104.18.40.252)

下面為 Wireshark 抓取的 https 流量包，展示了整個通信過程：建立 TCP 連接配接 --> SSL/TLS 握手 --> 應用資料加密傳輸：

Wireshark 抓包了解 HTTPS 協定

上面是一個實際的 SSL/TLS 握手過程，分為如下 5 步：

用戶端發送 Client Hello 消息給服務端；
服務端回應 Server Hello 消息；
服務端同時回應 Server Certificate、Server Key Exchange 和 Server Hello Done 消息；
用戶端發送 Client Key Exchange、Change Cipher Spec 和 Client Finished 消息；
服務端最後發送 Change Cipher Spec 和 Server Finished 消息；

下面我們分步分析每個階段的包的内容，看是否和前面的理論一緻。

用戶端發送 Client Hello 消息給服務端

Wireshark 抓包了解 HTTPS 協定

可以看出 TLS 協定确實分為兩層：TLS 記錄層、TLS 握手層，其中 TLS 握手層基于 TLS 記錄層。

另外用戶端發送的 Client Hello 消息當中包含的資訊也可以看到：

Version：用戶端支援的 TLS 版本号；
Random：用戶端生成的 32 位元組随機數；
Session ID：會話 ID；
Cipher Suites：用戶端支援的加密套件清單；
Compression Methods：用戶端支援的壓縮算法；

服務端回應 Server Hello 消息

Wireshark 抓包了解 HTTPS 協定

Server Hello 包含如下資訊：

Version：雙方支援的 TLS 版本号；
Random：服務端生成的 32 位元組随機數；
Session ID：會話 ID；
Cipher Suites：雙方協商的加密套件；
Compression Methods：壓縮算法；

服務端同時回應 Server Certificate、Server Key Exchange 和 Server Hello Done 消息

Wireshark 抓包了解 HTTPS 協定

可以看出每個 TLS 記錄層是一個消息，服務端同時回複了有 3 個消息：Server Certificate、Server Key Exchange、Server Hello Done。

從 Server Key Exchange 消息可以看出雙方密鑰協商使用的是 Diffie-Hellman (迪菲) 算法，該消息用于傳遞 Diffie-Hellman (迪菲) 算法的參數。

用戶端發送 Client Key Exchange、Change Cipher Spec 和 Client Finished 消息

Wireshark 抓包了解 HTTPS 協定

可以看出用戶端同時回複了 3 個消息：Client Key Exchange、Change Cipher Spec 和 Client Finished 消息。Client Key Exchange 的内容為 Diffie-Hellman (迪菲) 算法的參數，用于生成 premaster key，然後和雙方之前的随機數結合生成對稱密鑰。

服務端最後發送 Change Cipher Spec 和 Server Finished 消息

Wireshark 抓包了解 HTTPS 協定

服務端最後發送 Change Cipher Spec 和 Server Finished 消息，至此 SSL/TLS 握手完畢，接下來雙方會用對稱加密的方式加密傳輸資料。

Wireshark 抓包了解 HTTPS 協定