前言：本篇將介紹TLS握手的實際握手過程，TLS握手創(chuàng)建了Client和Server之間“被保護(hù)的通道”，2個單向通道用來保護(hù)批量數(shù)據(jù)的傳輸（通過Confidentiality、Integrity和Authentication），一個通道是從Client到Server，另一個是從Server到Client。本篇將介紹最基礎(chǔ)的握手 - 即握手采用的是RSA密鑰交換，并通過追條記錄（Record）的形式來闡述該過程。

????????在整個握手的過程中，Client和Server會交換并計算特定的值。上圖兩側(cè)的框是雙方所擁有的信息。開始時，Server已經(jīng)擁有了證書、公鑰和私鑰，

1、Handshake：Client Hello

????????第一條Record是Client Hello，里面包含5個部分

• Version
  • 包含了Client所支持的TLS/SSL的最高版本
• Random Number - 32 bytes / 256 bits
  • 前4個字節(jié)編碼時間戳（防止兩個擁有相同隨機數(shù)的不同的Client Hello相互發(fā)送信息）
• Session ID - 8 bytes / 32 bits
  • 00000...本篇中Client Hello的初始會話ID都是0
• Cipher Suites
  • Client會發(fā)送它所支持的密碼套件的列表，Server會從中挑選
• Extensions
  • 如果有擴展的話會包含在握手中，本篇不包含擴展

2、Handshake：Server?Hello

????????收到Client Hello后，Server會發(fā)出Server Hello，和Client Hello一樣，包含5部分

• Version
  • 包含了Server所支持的TLS/SSL的最高版本
• Random Number - 32 bytes / 256 bits
  • 前4個字節(jié)編碼時間戳
• Session ID - 8 bytes / 32 bits
  • Server生成的用于識別后續(xù)會話密鑰的值
• Cipher Suites
  • Server（從Client發(fā)送的列表中）挑選的密碼套件
• Extensions
  • 如果有擴展的話會包含在握手中，本篇不包含擴展

在Client Hello和Server Hello之后，Client和Server都獲得了額外的信息

• 兩者都知道了互相支持的TLS版本。如果Client發(fā)送說它支持TLS 1.3，Server返回說它支持TLS 1.2，這就表明兩者互相支持的最高的版本是TLS 1.2，兩者將用TLS 1.2協(xié)議進(jìn)行握手
• 兩者都知道了互相的隨機數(shù)（Client Random、Server Random）
• 兩者也知道未來會用來參考本次會話的ID
• 互相同意的用來保護(hù)這次TLS會話的密碼套件

3、Handshake：Certificate

????????這條記錄包含了Server證書和完整的證書鏈，Client會收到證書和公鑰。Client收到證書后會問自己2個問題：證書是否合法？（用CA公鑰進(jìn)行的簽名可以驗證其合法性，在此處Client擁有了其所需要的東西來驗證該簽名）；Server是否是該證書的真正擁有者？（驗證Server擁有與證書匹配的私鑰，會由Key Exchange Record所驗證）

4、Handshake：Server Hello Done

????????這是一條空的Record，表明Server此時沒有更多信息進(jìn)行發(fā)送；然而，握手的其他變體可能會要求Server發(fā)送更多信息。

5、Handshake：Client Key Exchange

????????Client Key Exchange有2個主要目的

• 創(chuàng)建相互的密鑰材料（例如，SEED?Value種子值，Client和Server兩者都用來生成會話密鑰）
• 證明Server確實是該證書的擁有者

????????2個目的都將由特殊的值所達(dá)成，即 Pre Master Secret，預(yù)主密鑰。上圖中用紅色虛線框描述，表明該值是加密發(fā)送的

• Pre Master Secret 的生成
  • Client生成 Pre-Master-Secret （包含48個字節(jié)）
    • 2 bytes - TLS/SSL Version
    • 46 bytes - Random（隨機生成的）
  • 之后，Pre-Master-Secret 會被Server的公鑰進(jìn)行加密（Client已經(jīng)有了，因為前面的Record中Server已經(jīng)發(fā)送了）
  • Pre-Master-Secret 被加密后進(jìn)行在線傳輸，唯一能提取該加密信息的，是擁有與之相匹配的私鑰的一方，即有對應(yīng)私鑰的Server
  • 現(xiàn)在，兩者就都擁有了?Pre-Master-Secret
• Pre Master Secret 的生效（在本例中，該值被用作種子值，來生成TLS會話密鑰）
  • 雙方都有了匹配的SEED Value
    • 種子值被用來生成會話密鑰
    • 預(yù)主密鑰被用來生成主密鑰（Master Secret）[ 將其他值與PreMasterSecret相結(jié)合，這些值是“master secret”文字字符串（包含在RFC里了）、Client Random和Server Random，這4個值會相互結(jié)合來生成Master Secret?]
    • 主密鑰被用來生成會話密鑰?[ 將其他值與Master Secret相結(jié)合，這些值是“Key expansion”文字字符串、Client Random和Server Random，這4個值會相互結(jié)合來生成會話密鑰?]
      • 至少生成4個會話密鑰（2套不同的密鑰）：
        • 保護(hù)Client發(fā)送信息的Client Encryption Key和Client HMAC Key
        • 保護(hù)Server發(fā)送信息的Server Encryption Key和Server HMAC Key
  • 
  • 特定加密協(xié)議需要 I.V. 即 Initializational Vector，初始化向量，這是（PRF）計算必要的I.V.的步驟
  • 計算涉及PRF - Pseudo Random Function，偽隨機數(shù)函數(shù)
    • 生成任意長度的摘要的哈希算法

????????到此，Client和Server雙方都有了完全相同的會話密鑰；但是，Client或Server并不知道另一方擁有相同的密鑰。

????????因而，余下的握手將給雙方證明：另一方擁有正確的會話密鑰。

6、Change Cipher Spec（不是Handshake Record）

? ? ? ? 該記錄表明Client已做好安全通話的一切準(zhǔn)備（意味著它可以計算出會話密鑰了）。我們可以閱讀該記錄，Client在說，它做好準(zhǔn)備去更改由Client和Server所指定的密碼。

7、Handshake：Finished

• 向Server證明：Client有正確的會話密鑰
• 這會由特定的值（Encrypted Verification）來完成，過程如下
  • Client計算出之前所有握手記錄（5個）的哈希，這5個記錄會一起被哈希，生成Handshake Hash
  • 然后，Handshake Hash會與其他值（“client finish”字符串和Master Secret）相結(jié)合來生成驗證數(shù)據(jù)（Verification Data）
  • 最終，驗證數(shù)據(jù)會被Client Session Keys加密，生成加密驗證
    • Server用自己的Client會話密鑰副本進(jìn)行驗證
    • 驗證Client和Server“看見”相同的握手記錄

• 

• 理論上，Server也看見了之前5個握手記錄（即Handshake Hash），“client finished”字符串，同時Server也有Mater Secret，這表明Server能合并得到相同的Verification Data；之后，Server收到加密驗證后，用Client Session Key副本去進(jìn)行解密，如果得到的結(jié)果和Server自己合并得到的驗證數(shù)據(jù)相同，這就向Server表明，Client擁有相同的會話密鑰。如果有人在Client發(fā)送出Client Hello后，Server接受到之前，進(jìn)行篡改，兩邊的Verification Data會不匹配

8、Change Cipher Spec（不是Handshake Record）

????????該記錄表明Server已做好安全通話的一切準(zhǔn)備（意味著它可以計算出會話密鑰了）

9、Handshake：Finished

• 向Client證明：Server有正確的會話密鑰
• 類似的過程
  • Client計算出之前所有握手記錄（6個）的哈希，得到Handshake Hash
  • Handshake Hash會與其他值（“server?finish”字符串和Master Secret）相結(jié)合來生成驗證數(shù)據(jù)（Verification Data）
  • 驗證數(shù)據(jù)會被Server Session Keys加密，生成加密驗證
    • Client用自己的Server會話密鑰副本進(jìn)行驗證

• 

? ? ? ? 在此刻的握手中，Client和Server都計算出相同的會話密鑰，并且相互向?qū)Ψ阶C明自己有正確的會話密鑰。這意味著兩者可以開始分享批量數(shù)據(jù)了，并用協(xié)商好的會話密鑰保護(hù)該數(shù)據(jù)。

? ? ? ? 以上就是TLS握手（我們闡述的是basic handshake）的全部過程

? ? ? ? 需要知道的是，TLS握手發(fā)生在我們每次訪問HTTPS網(wǎng)站的時候，或者每次我們鏈接SSL VPN（Virtual Private Network）的時候

參考文獻(xiàn)

1、網(wǎng)站：https://www.practicalnetworking.net/：practical TLS