<!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進行封裝。
參考文檔
- RFC4346: The Transport Layer Security (TLS) Protocol Version 1.1
- 小林coding的《圖解網絡》