SSL TLS 握手過程詳解

我們知道，http 協議都是明文傳輸內容，在早期只展示靜態內容時沒有問題。伴隨著網際網路的快速發展，人們對於網路傳輸安全性的要求也越來越高，https 協議因此出現。如下圖所示，在 https 加密中真正起作用的其實是 ssl/tls 協議。ssl/tls 協議作用在 http 協議之下，對於上層應用來說，原來的傳送接收資料流程不變，這就很好地相容了老的 http 協議，這也是軟體開發中分層實現的體現。

ssl/tls 握手是為了安全地協商出乙份對稱加密的秘鑰，這個過程很有意思，下面我們一起來了解一下。

上圖大致描述了 ssl/tls 的握手過程，但缺少了一些資訊不利於理解，我會在後面的講解裡再列出來。

client hello

握手第一步是客戶端向服務端傳送 client hello 訊息，這個訊息裡包含了乙個客戶端生成的隨機數random1、客戶端支援的加密套件（support ciphers）和 ssl version 等資訊。通過 wireshark 抓包，我們可以看到如下資訊：

第二步是服務端向客戶端傳送 server hello 訊息，這個訊息會從 client hello 傳過來的 support ciphers 裡確定乙份加密套件，這個套件決定了後續加密和生成摘要時具體使用哪些演算法，另外還會生成乙份隨機數random2。注意，至此客戶端和服務端都擁有了兩個隨機數（random1+ random2），這兩個隨機數會在後續生成對稱秘鑰時用到。

這一步是服務端將自己的證書下發給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過後取出證書中的公鑰。

certificate request 是服務端要求客戶端上報證書，這一步是可選的，對於安全性要求高的場景會用到。

server hello done

server hello done 通知客戶端 server hello 過程結束。

客戶端收到服務端傳來的證書後，先從 ca 驗證該證書的合法性，驗證通過後取出證書中的服務端公鑰，再生成乙個隨機數random3，再用服務端公鑰非對稱加密random3生成premaster key。

client key exchange

上面客戶端根據伺服器傳來的公鑰生成了premaster key，client key exchange 就是將這個 key 傳給服務端，服務端再用自己的私鑰解出這個premaster key得到客戶端生成的random3。至此，客戶端和服務端都擁有random1+random2+random3，兩邊再根據同樣的演算法就可以生成乙份秘鑰，握手結束後的應用層資料都是使用這個秘鑰進行對稱加密。為什麼要使用三個隨機數呢？這是因為 ssl/tls 握手過程的資料都是明文傳輸的，並且多個隨機數種子來生成秘鑰不容易被暴力破解出來。客戶端將premaster key傳給服務端的過程如下圖所示：

這一步是客戶端通知服務端後面再傳送的訊息都會使用前面協商出來的秘鑰加密了，是一條事件訊息。

這一步對應的是 client finish 訊息，客戶端將前面的握手訊息生成摘要再用協商好的秘鑰加密，這是客戶端發出的第一條加密訊息。服務端接收後會用秘鑰解密，能解出來說明前面協商出來的秘鑰是一致的。

change cipher spec(server)

這一步是服務端通知客戶端後面再傳送的訊息都會使用加密，也是一條事件訊息。

encrypted handshake message(server)

這一步對應的是 server finish 訊息，服務端也會將握手過程的訊息生成摘要再用秘鑰加密，這是服務端發出的第一條加密訊息。客戶端接收後會用秘鑰解密，能解出來說明協商的秘鑰是一致的。

到這裡，雙方已安全地協商出了同乙份秘鑰，所有的應用層資料都會用這個秘鑰加密後再通過 tcp 進行可靠傳輸。

如果每次重連都要重新握手還是比較耗時的，所以可以對握手過程進行優化。從下圖裡我們看到 client hello 訊息裡還附帶了上一次的 session id，服務端接收到這個 session id 後如果能復用就不再進行後續的握手過程。

除了上述的 session 復用，ssl/tls 握手還有一些優化技術，例如 false start、session ticket 等

SSL TLS 握手過程詳解

SSL TLS 握手過程詳解

SSL TLS握手過程

SSL TLS 握手過程

相關推薦