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協議執行機制的概述

圖解SSL/TLS協議

session id & Session ticket參考

三種解密 HTTPS 流量的方法介紹
————————————————
版權宣告：本文為CSDN博主「BlackFee」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/u013315560/article/details/108286278