基於ECDHE的TLS握手流程
<!doctype html>3.3 基於ECDHE的TLS握手流程
3.3 基於ECDHE的TLS握手流程
上圖便是一個基於HTTPS通訊的完整過程，涉及：
- TCP三次握手
- TLS握手
- 加密數據傳輸
- TCP四次揮手
下面主要着重介紹基於ECDHE的TLS的握手流程。
3.3.1 TLS第一次握手
客戶端首先發送一個【ClientHello】消息作為TLS握手的開始。該消息中主要包含：TLS的版本號， 客戶端隨機數(Client Random), 密鑰套件列表以及SessionID信息。
如果報文中的SessionID不為空，則說明客戶端想復用此session的密碼信息。服務端如果同意則在ServerHello中使用相同的SessionID， 如果不同意則重新生成一個新的SessionID。
這裡說一下：密碼套件的格式。
TLS的密鑰套件不同於IPSec密鑰套件。
- IPSec密鑰套件中加密算法、哈希算法、認證算法可以互相自由組合，協商的是每一種算法，最後組合成一個密碼套件。
- 而TLS則直接協商密碼套件，每一種密碼套件中密碼算法組合是固定的。
TLS密碼套件組合方式：
TLS——密鑰交換算法——簽名算法——WITH——加密算法——摘要算法
其中密鑰交換算法和簽名算法可以合二為一。
3.3.2 TLS第二次握手
TLS第二次握手報文包含的內容比較多。有時候一個報文包含所有載荷，有時各個載荷單獨發送。如果看到單獨發送的載荷，莫要奇怪。
第二次握手主要包含了四個載荷：
- Server Hello
- Certificate
- Server Key Exchange
- Server Hello Done
下面分別介紹這四個載荷：
Server Hello載荷內容
Server Hello中的內容與Client Hello中基本一致。包括：TLS版本號， 服務器端的隨機數(Server Random), 服務器端想要使用的SessionID，服務器端選擇的加密套件。
如果此SessionID與ClientHello中的SessionID相同，則說明服務器同意復用此session; 如果不同則說明需要進行重新協商。我這次抓的報文兩者sessionID並不相同，因此需要完整的TLS協商流程。
服務端選擇的算法套件是：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030), 它的意思是：
-
密鑰交換算法採用：ECDHE
-
簽名算法採用：RSA
-
加密算法採用：AES對稱算法，密鑰長度為256bit, 模式為：GCM。
-
摘要算法採用：SHA284
服務端證書載荷
證書載荷中可以包含多個證書。一個或者兩個比較常見。如果是一個，則是服務端證書；如果是兩個，則另一個一般是服務端CA，用來驗證服務端證書。
Server Key Exchange
由於採用的是ECDHE進行密鑰交換，因此服務端需要將採用的橢圓曲線信息，公共值信息發送給客戶端。此外為了防止信息被篡改，服務端使用RSA算法對DH公鑰做一個簽名。這個Pubkey？？？
Server Hello Done
最後發送一個ServerHelloDone消息，表明：「這就是Server Hello階段發送的所有信息，你可以忙活了」。它的報文內容很簡單，啥也沒有。
握手階段交互完畢，通過Hello階段握手，客戶端和服務端交換的信息如下：Client Random, Server Random, 使用的橢圓曲線，橢圓曲線公鑰。
3.3.3 TLS第三次握手
客戶端收到服務端的ServerHello階段信息後，首先會對服務端的證書進行驗證，驗證服務端證書可能涉及認證鏈的問題。如果驗證通過，說明當前服務器身份沒有問題。如果驗證不通過，則會提示相應的錯誤信息(好像是Bad certificate)。對服務端的身份認證一般情況下是可以設置的，客戶端可以選擇驗證也可以不驗證。
服務端驗證完畢後，客戶端會生成一個隨機數，作為ECDHE的臨時私鑰，並通過服務端在ServerKeyExchange中發送的橢圓曲線參數，計算出自己的ECDHE公鑰信息。然後通過ClientKeyExchange發送給服務端。
之後，客戶端會根據手裡中的信息：Client Random, Server Random, ECDHE協商出的共享密鑰，計算出會話密鑰(主密鑰)。 其他密鑰都是在此基礎上依次獲取的。密鑰計算完畢後，發送ChangeCipherSpec消息，通知服務端後續報文採用新協商的安全參數進行安全通訊。
最後發送一個Encrypted Handshake Message消息，把之前所有的握手報文做一個摘要，然後使用協商的對稱密鑰進行加密發送給服務端。依次來驗證雙方本次握手協商的安全參數是否可用。
3.3.4 TLS第四次握手
第四次握手與第三次握手非常相似。服務器端收到ClientKeyExchange後，獲取到裏面的客戶端DH算法公鑰，計算出ECDHE協商出的共享密鑰。 然後在利用手中的Client Random, Server Random, ECDHE協商出的共享密鑰計算出會話密鑰。最後根據會話密鑰依次生成其他密鑰。
在此過程中服務端同樣會發送ChangeCipherSpec，通知客戶端，麻溜採用新協商的安全參數進行通訊，以後發給你的數據全部進行加密。此外服務端同樣對所有的握手報文做一個摘要，並進行加密然後給客戶端發送一個Encrypted Handshake Message消息，驗證客戶端是否可以正常解密。
至此， 基於ECDHE的TLS協商完畢。之後雙方使用協商出的安全參數進行加密通訊。加密的應用層協議使用TLS Record Layer Protocal進行封裝。
