<!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進行封裝。
