TLS握手過程
握手簡述（以RSA為例）：
- client hello:客戶端給出TLS協議版本號，支持的加密算法、隨機數Client random、擴展字段
- server hello:服務端確認雙方可支持的加密算法，並把數字證書下發給客戶端。同時也會生成一個隨機數Server random
- 客戶端驗證證書的有效性，並重新生成一個隨機數Pre-main secret，使用證書中的公鑰加密隨機數，發送給服務端
- 服務端使用私鑰獲取隨機數
- 客戶端與服務端根據約定的加密算法，使用前面的三個隨機數，生成對話密鑰Session key，用來加密后續會話。
TLS需要知道的名詞
1.會話密鑰（Session key）
這是握手的最終結果。它是對稱密碼的密鑰，並允許客戶端和服務器相互加密消息。
2.客戶端隨機（Client random）
這是由客戶端創建的32個字節的序列。它對於每個連接都是唯一的，並且應該包含四個字節的時間戳，后跟28個隨機字節。最近，谷歌瀏覽器切換為使用32個字節的隨機數，以防止客戶端指紋。這些隨機值通常稱為隨機數（nonce）。
3.服務器隨機數(Server random)
服務器隨機數與客戶端隨機數相同，只是服務器生成的隨機數相同。
4.Pre-main密鑰(Pre-main secret)
這是一個48字節的數據塊。它可以與客戶端隨機變量和服務器隨機變量結合使用，以使用“偽隨機函數”（PRF）創建會話密鑰(Session key）。
5.密碼套件（Cipher suite）
CipherSpecs 用於認證加密算法和信息摘要算法的組合，通信雙方必須同意這個密碼規范才能進行通信。而 CipherSuites 則定義了 SSL / TLS 安全連接中所使用的加密算法的組合，該組合包含三種不同的算法：
- 握手期間所使用的的密鑰交換和認證算法 (最常用的是 RSA 算法)
- 加密算法 (用於握手完成后的對稱加密，常用的有 AES、3DES等)
- 信息摘要算法 (常用的有 SHA-256、SHA-1 和 MD5 等)
CipherSuites是用於組合構成TLS連接的算法的唯一標識符。它為以下列出的每個功能定義一種算法：
- 密鑰建立（通常是Diffie-Hellman變體或RSA）
- 認證（證書類型）
- 機密性（對稱密碼）
- 完整性（哈希函數）
例如，密碼套件是“ ECDHE-ECDSA-AES256-GCM-SHA384”，它定義了一個使用以下內容的會話：
- Elliptic Curve Diffie-Hellman Ephemeral（ECDHE）密鑰交換以建立密鑰
- Elliptic Curve Digital Signature Algorithms（ECDSA）進行身份驗證
- 256-bit Advanced Encryption Standard in Galois/Counter mode (GCM) 用於確保機密性
- 384位的SHA(安全哈希算法)確保完整性
RSA握手
消息1：Client Hello
client hello包含客戶端要使用的協議版本，以及一些開始握手的其他信息，包括客戶端隨機數（client random）和密碼套件（cipher suites）列表。現行瀏覽器還包括他們要查找的主機名，稱為服務器名稱指示（SNI）。SNI使Web服務器可以在同一IP地址上托管多個域。
消息2：Server Hello
收到client hello后，服務器將選擇進行握手的參數。密碼套件的選擇確定執行哪種類型的握手。服務器“ hello”消息包含服務器隨機數，服務器選擇的密碼套件以及服務器的證書。證書包含服務器的公鑰和域名。
消息3：Client Key Exchange
在驗證證書是受信任的並且屬於他們嘗試訪問的站點之后，客戶端將創建一個隨機的pre-main secret。此密鑰使用證書中的公鑰加密，然后發送到服務器。
收到此消息后，服務器將使用其私鑰來解密此密鑰。既然雙方都有pre-main secret，並且客戶端和服務器都具有隨機性，那么他們都可以導出相同的會話密鑰。然后，他們交換一條短消息以指示他們發送的下一條消息將被加密。
當客戶端和服務器交換“完成”消息時，握手正式完成。正式的文本描述是：使用session key加密“client finished” or “server finished” 。雙方之間的任何后續通信都使用session key加密。
這種握手優點是，在一個步驟中將密鑰交換和身份驗證結合在一起。理論上如果服務器可以正確導出會話密鑰，則它們必須有權訪問私鑰，因此必須是證書的所有者。
這種握手的缺點是，它所保護的消息僅與私鑰一樣安全。假設第三方已記錄了握手和隨后的通信。如果該方將來可以訪問私鑰，則他們將能夠解密主密碼並導出會話密鑰。這樣他們就可以解密整個消息。即使證書已過期或吊銷，也是如此。這將導致我們采用另一種形式的握手，即使私鑰遭到破壞，該握手也可以提供機密性。
Ephemeral Diffie-Hellman 握手
它使用兩種不同的機制：一種用於建立shared pre-main secret，另一種用於認證服務器。這依賴的關鍵功能是Diffie-Hellman密鑰協商算法。
算法工作原理類似如下：
- a有密鑰a，將g^a發送給b
- b有密鑰b，將g^b發送給a
- a計算(gb)a
- b計算(ga)b
- a和b都以gab結尾，這是他們的共同密鑰
消息1：Client Hello
就像在RSA中一樣，client hello包含協議版本，客戶端隨機值，密碼套件列表以及SNI擴展（可選）。
消息2：Server Hello
收到client hello后，服務器將選擇進行握手的參數，包括ECDHE的曲線。服務器“ hello”消息包含服務器隨機數，服務器選擇的密碼套件以及服務器的證書。
RSA和Diffie-Hellman握手在這一點上因新的消息類型而開始不同。
消息3：Server Key Exchange
為了啟動Diffie-Hellman密鑰交換，服務器需要選擇一些啟動參數並將其發送給客戶端-這與我們上面描述的g^a相對應。服務器還需要一種方法來證明它具有對私鑰的控制權，因此服務器會計算到目前為止所有消息的數字簽名。Diffie-Hellman參數和簽名都在此消息中發送。
消息4：Client Key Exchange
在驗證證書是受信任的並且屬於他們嘗試訪問的站點之后，客戶端將驗證從服務器發送的數字簽名。他們還向客戶端發送Diffie-Hellman握手的一半（對應於上面的g^b）。
此時，雙方都可以根據Diffie-Hellman參數（對應於上面的gab）計算出pre-main secret。使用pre-main secret以及客戶端和服務器的隨機密鑰，它們可以派生相同的會話密鑰。然后，他們交換一條短消息以指示他們發送的下一條消息將被加密。
就像在RSA握手中一樣，當客戶端和服務器交換“Finished”消息時，此握手已正式完成。雙方之間的任何后續通信都使用會話密鑰加密。
Tips:與RSA相比采用DH算法后，Premaster secret不需要傳遞，雙方只要交換各自的參數，就可以算出這個隨機數。
Abbreviated handshake
TLS提供了一項好的機制，稱為“會話恢復（session resumption）”。如果客戶端先前已經與服務器建立了會話，並嘗試再次連接，則可以使用Abbreviated handshake。有兩種機制可以實現：會話ID和會話票證（session IDs and session tickets）。
會話ID要求服務器保持會話狀態（即會話密鑰）就緒，以防需要恢復先前的會話。對於會話票證，服務器在初始握手期間將會話票證（由用票證密鑰加密的會話密鑰組成）發送給客戶端。在恢復會話時，客戶端將加密的密鑰發送回服務器，由服務器解密並恢復會話。無需使用私鑰來恢復會話。
Firefox和Chrome是支持會話票證的主要瀏覽器。所有其他現行瀏覽器都通過會話ID支持恢復。大規模使用這些技術時面臨的挑戰之一是負載平衡。為了使服務器恢復連接，它需要具有先前建立的會話密鑰。如果訪問者嘗試恢復與新服務器的連接，則該服務器需要以某種方式獲取原始會話密鑰（original session key ）。
會話恢復的主要問題在於，這並不意味着可以擴展到負載平衡的服務器。如果客戶端在一個服務器上啟動會話，則無法在另一台服務器上恢復該會話。這不是協議的失敗，只是開源Web服務器中缺少的功能。
通過Keyless SSL，我們引入了高級會話恢復功能來解決此問題。這包括通過會話票證在全球范圍內恢復會話，以及通過會話ID在數據中心內恢復會話。會話恢復使重復訪問者的連接時間很快，因為無需返回到密鑰服務器即可恢復連接。
補充知識
SNI：
在TLS握手階段，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什么通常一台服務器只能有一張數字證書的原因。
對於虛擬主機的用戶來說，這當然很不方便。2006年，TLS協議加入了一個Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。SNI使Web服務器可以在同一IP地址上托管多個域。
Keyless服務
放到CDN上的網站，可以不用提供自己的私鑰，也能使用SSL加密鏈接。
如何做到：將密鑰放到密鑰服務器上
數字證書（digital certificate)
在非對稱加密通信過程中，服務器需要將公鑰發送給客戶端，在這一過程中，公鑰很可能會被第三方攔截並替換，然后這個第三方就可以冒充服務器與客戶端進行通信，這就是傳說中的“中間人攻擊”(man in the middle attack)。解決此問題的方法是通過受信任的第三方交換公鑰，具體做法就是服務器不直接向客戶端發送公鑰，而是要求受信任的第三方，也就是證書認證機構 (Certificate Authority, 簡稱 CA)將公鑰合並到數字證書中，然后服務器會把公鑰連同證書一起發送給客戶端，私鑰則由服務器自己保存以確保安全。
證書驗證過程
- 服務端生成公鑰和私鑰
- 服務端發送公鑰給CA
- CA生成證書給服務端
- 服務端再客戶端請求時發送證書給客戶端
- 客戶端接收到證書之后發送給CA驗證證書有效性
- 確認證書有效之后，才可以進行后續https通信
驗證什么
- 檢查數字簽名
- 驗證證書鏈
- 驗證證書有效期
- 驗證證書撤回狀態
- 證書中有什么
- 證書所有者的公鑰
- 證書所有者的專有名稱
- 證書頒發機構的專有名稱
- 證書的有效起始日期
- 證書的過期日期
- 證書數據格式的版本號
- 序列號，這是證書頒發機構為該證書分配的唯一標識符
流量解密
工具：wireshark
法一:使用私鑰解密
條件：擁有私鑰證書
缺點：無法解密 ECDHE 進行密鑰交換的加密流量。
步驟
配置wireshark
編輯–>首選項–>protocols–>TLS
按照下圖中填寫IP地址、端口、協議、以及私鑰文件。
保存配置，重新打開wireshark捕獲流量，然后訪問私鑰對應的網站就可以解密流量了。
法二:SSLKEYLOGFILE
此方法對使用ECDHE 密鑰交換方式的流量也可以，不需要私鑰
步驟
添加環境變量：SSLKEYLOGFILE
Firefox 和 Chrome 會將每個 HTTPS 連接產生的 Premaster Secret 或 Master Secret 存儲在環境變量SSLKEYLOGFILE對應的文件路徑中。
Wireshark配置：
TLS debug file : 解密過程中的日志會記錄到這里，可選配置
(Pre)-Master-Secret log filename 選項中選擇環境變量SSLKEYLOGFILE配置的文件路徑。
配置完成后，再訪問 HTTPS 網站，sslkeylog.log 文件中將會有瀏覽器寫入的數據。
確認之后就可以重新打開Wireshark進行抓包，可以看到解密流量了
參考資料
SSL/TLS協議運行機制的概述
三種解密 HTTPS 流量的方法介紹
————————————————
版權聲明：本文為CSDN博主「BlackFee」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/u013315560/article/details/108286278