SSL/TLS 握手過程詳解

時間 2019-11-16

標籤 ssl tls 握手過程詳解欄目 SSL 简体版

原文原文鏈接

咱們知道，HTTP 協議都是明文傳輸內容，在早期只展現靜態內容時沒有問題。伴隨着互聯網的快速發展，人們對於網絡傳輸安全性的要求也愈來愈高，HTTPS 協議所以出現。如上圖所示，在 HTTPS 加密中真正起做用的實際上是 SSL/TLS 協議。SSL/TLS 協議做用在 HTTP 協議之下，對於上層應用來講，原來的發送接收數據流程不變，這就很好地兼容了老的 HTTP 協議，這也是軟件開發中分層實現的體現。html

SSL/TLS 握手是爲了安全地協商出一份對稱加密的祕鑰，這個過程頗有意思，下面咱們一塊兒來了解一下。算法

如下內容須要你對加解密、數字簽名和數字證書的概念有必定了解，這裏有一篇文章能夠幫你快速瞭解這幾個概念。segmentfault

SSL/TLS 握手過程

上圖大體描述了 SSL/TLS 的握手過程，但缺乏了一些信息不利於理解，我會在後面的講解裏再列出來。安全

Client Hello

握手第一步是客戶端向服務端發送 Client Hello 消息，這個消息裏包含了一個客戶端生成的隨機數 Random1、客戶端支持的加密套件（Support Ciphers）和 SSL Version 等信息。經過 Wireshark 抓包，咱們能夠看到以下信息：服務器

Wireshark 抓包的用法能夠參考這篇文章網絡

Server Hello

第二步是服務端向客戶端發送 Server Hello 消息，這個消息會從 Client Hello 傳過來的 Support Ciphers 裏肯定一份加密套件，這個套件決定了後續加密和生成摘要時具體使用哪些算法，另外還會生成一份隨機數 Random2。注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+ Random2），這兩個隨機數會在後續生成對稱祕鑰時用到。app

Certificate

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

Server Key Exchange

若是是DH算法，這裏發送服務器使用的DH參數。RSA算法不須要這一步。post

Certificate Request

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

Server Hello Done

Server Hello Done 通知客戶端 Server Hello 過程結束。

Certificate Verify

客戶端收到服務端傳來的證書後，先從 CA 驗證該證書的合法性，驗證經過後取出證書中的服務端公鑰，再生成一個隨機數 Random3，再用服務端公鑰非對稱加密 Random3 生成 PreMaster Key。

Client Key Exchange

上面客戶端根據服務器傳來的公鑰生成了 PreMaster Key，Client Key Exchange 就是將這個 key 傳給服務端，服務端再用本身的私鑰解出這個 PreMaster Key 獲得客戶端生成的 Random3。至此，客戶端和服務端都擁有 Random1 + Random2 + Random3，兩邊再根據一樣的算法就能夠生成一份祕鑰，握手結束後的應用層數據都是使用這個祕鑰進行對稱加密。爲何要使用三個隨機數呢？這是由於 SSL/TLS 握手過程的數據都是明文傳輸的，而且多個隨機數種子來生成祕鑰不容易被暴力破解出來。客戶端將 PreMaster Key 傳給服務端的過程以下圖所示：

Change Cipher Spec(Client)

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

Encrypted Handshake Message(Client)

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

Change Cipher Spec(Server)

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

Encrypted Handshake Message(Server)

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

Application Data

到這裏，雙方已安全地協商出了同一份祕鑰，全部的應用層數據都會用這個祕鑰加密後再經過 TCP 進行可靠傳輸。

雙向驗證

前面提到 Certificate Request 是可選的，下面這張圖展現了雙向驗證的過程：

握手過程優化

若是每次重連都要從新握手仍是比較耗時的，因此能夠對握手過程進行優化。從下圖裏咱們看到 Client Hello 消息裏還附帶了上一次的 Session ID，服務端接收到這個 Session ID 後若是能複用就再也不進行後續的握手過程。

除了上述的 Session 複用，SSL/TLS 握手還有一些優化技術，例如 False Start、Session Ticket 等，這方面的介紹具體能夠參考這篇文章。

總結

前面咱們一塊兒詳細地瞭解了整個 SSL/TLS 的握手過程，這部分知識在平時的開發過程當中不多用到，但能讓咱們更清楚地瞭解 HTTPS 的工做原理，而不只僅是隻知道 HTTPS 會加密數據十分安全。同時這個過程也是各類加密技術的一個經典運用，也能幫助咱們加深加密相關技術的理解。最後，建議你們也用 Wireshark 實際抓包體驗一下這個過程來加深印象，enjoy~