HTTPS詳解二：SSL / TLS 工做原理和詳細握手過程

HTTPS 詳解系列：
HTTPS 詳解一：附帶最精美詳盡的 HTTPS 原理圖
HTTPS 詳解二：SSL / TLS 工做原理和詳細握手過程

前言

在上篇文章HTTPS詳解一中，我已經爲你們介紹了 HTTPS 的詳細原理和通訊流程，但總感受少了點什麼，應該是少了對安全層的針對性介紹，那麼這篇文章就算是對HTTPS 詳解一的補充吧。還記得這張圖吧。

HTTPS 和 HTTP的區別

顯然，HTTPS 相比 HTTP最大的不一樣就是多了一層 SSL (Secure Sockets Layer 安全套接層)或 TLS (Transport Layer Security 安全傳輸層協議)。有了這個安全層，就確保了互聯網上通訊雙方的通訊安全，那麼這個安全層是怎麼工做的，SSL / TLS 握手過程又是怎樣的呢？本文將對這些問題一一解答。

一、SSL / TLS 以及 SSL / TLS 握手的概念

SSL 和 TLS 協議能夠爲通訊雙方提供識別和認證通道，從而保證通訊的機密性和數據完整性。TLS 協議是從Netscape SSL 3.0協議演變而來的，不過這兩種協議並不兼容，SSL 已經逐漸被 TLS 取代，因此下文就以 TLS 指代安全層。 TLS 握手是啓動 HTTPS 通訊的過程，相似於 TCP 創建鏈接時的三次握手。 在 TLS 握手的過程當中，通訊雙方交換消息以相互驗證，相互確認，並確立它們所要使用的加密算法以及會話密鑰 (用於對稱加密的密鑰)。能夠說，TLS 握手是 HTTPS 通訊的基礎部分。

二、TLS 握手過程當中發生了什麼

咱們已經知道 TLS 握手的目的是創建安全鏈接，那麼通訊雙方在這個過程當中究竟幹了什麼呢？下面就是答案：

• 商定雙方通訊所使用的的 TLS 版本 (例如 TLS1.0, 1.2, 1.3等等)；
• 肯定雙方所要使用的密碼組合；
• 客戶端經過服務器的公鑰和數字證書 (上篇文章已有介紹)上的數字簽名驗證服務端的身份；
• 生成會話密鑰，該密鑰將用於握手結束後的對稱加密。

三、TLS 握手詳細過程

下面來看 TLS 握手的詳細過程 (注：此圖與HTTPS詳解一中的 HTTPS 原理圖的流程大體相同，不一樣的是此圖把重點放在了TLS握手的相關概念上)：

SSL / TLS 握手詳細過程

1. "client hello"消息：客戶端經過發送"client hello"消息向服務器發起握手請求，該消息包含了客戶端所支持的 TLS 版本和密碼組合以供服務器進行選擇，還有一個"client random"隨機字符串。
2. "server hello"消息：服務器發送"server hello"消息對客戶端進行迴應，該消息包含了數字證書，服務器選擇的密碼組合和"server random"隨機字符串。

3. 驗證：客戶端對服務器發來的證書進行驗證，確保對方的合法身份，驗證過程能夠細化爲如下幾個步驟：

   1. 檢查數字簽名
   2. 驗證證書鏈 (這個概念下面會進行說明)
   3. 檢查證書的有效期
   4. 檢查證書的撤回狀態 (撤回表明證書已失效)
4. "premaster secret"字符串：客戶端向服務器發送另外一個隨機字符串"premaster secret (預主密鑰)"，這個字符串是通過服務器的公鑰加密過的，只有對應的私鑰才能解密。
5. 使用私鑰：服務器使用私鑰解密"premaster secret"。
6. 生成共享密鑰：客戶端和服務器均使用 client random，server random 和 premaster secret，並經過相同的算法生成相同的共享密鑰 KEY。
7. 客戶端就緒：客戶端發送通過共享密鑰 KEY加密過的"finished"信號。
8. 服務器就緒：服務器發送通過共享密鑰 KEY加密過的"finished"信號。
9. 達成安全通訊：握手完成，雙方使用對稱加密進行安全通訊。

四、TLS 握手過程當中的一些重要概念

1. 數字證書 (digital certificate)：在非對稱加密通訊過程當中，服務器須要將公鑰發送給客戶端，在這一過程當中，公鑰極可能會被第三方攔截並替換，而後這個第三方就能夠冒充服務器與客戶端進行通訊，這就是傳說中的「中間人攻擊」(man in the middle attack)。解決此問題的方法是經過受信任的第三方交換公鑰，具體作法就是服務器不直接向客戶端發送公鑰，而是要求受信任的第三方，也就是證書認證機構 (Certificate Authority, 簡稱 CA)將公鑰合併到數字證書中，而後服務器會把公鑰連同證書一塊兒發送給客戶端，私鑰則由服務器本身保存以確保安全。數字證書通常包含如下內容：

   1. 證書全部者的公鑰
   2. 證書全部者的專有名稱
   3. 證書頒發機構的專有名稱
   4. 證書的有效起始日期
   5. 證書的過時日期
   6. 證書數據格式的版本號
   7. 序列號，這是證書頒發機構爲該證書分配的惟一標識符

      ... ...

2. 數字簽名 (digital signature)：這個概念很好理解，其實跟人的手寫簽名相似，是爲了確保數據發送者的合法身份，也能夠確保數據內容未遭到篡改，保證數據完整性。與手寫簽名不一樣的是，數字簽名會隨着文本數據的變化而變化。具體到數字證書的應用場景，數字簽名的生成和驗證流程以下：

   1. 服務器對證書內容進行信息摘要計算 (經常使用算法有 SHA-256等)，獲得摘要信息，再用私鑰把摘要信息加密，就獲得了數字簽名
   2. 服務器把數字證書連同數字簽名一塊兒發送給客戶端
   3. 客戶端用公鑰解密數字簽名，獲得摘要信息
   4. 客戶端用相同的信息摘要算法從新計算證書摘要信息，而後對這兩個摘要信息進行比對，若是相同，則說明證書未被篡改，不然證書驗證失敗
3. 證書鏈 (certificate chain)：證書鏈，也稱爲證書路徑，是用於認證明體合法身份的證書列表，具體到 HTTPS 通訊中，就是爲了驗證服務器的合法身份。之因此使用證書鏈，是爲了保證根證書 (root CA certificate)的安全，中間層能夠看作根證書的代理，起到了緩衝的做用，以下圖所示，這裏還以 B 站證書爲例：

證書鏈

證書鏈從根證書開始，而且證書鏈中的每一級證書所標識的實體都要爲其下一級證書籤名，而根證書自身則由證書頒發機構簽名。客戶端在驗證證書鏈時，必須對鏈中全部證書的數字簽名進行驗證，直到達到根證書爲止。

4.密碼規範和密碼組合 (CipherSpecs 和 CipherSuites)：通訊雙方在安全鏈接中所使用的算法必須符合密碼安全協議的規定，CipherSpecs 和 CipherSuites 正好定義了合法的密碼算法組合。CipherSpecs 用於認證加密算法和信息摘要算法的組合，通訊雙方必須贊成這個密碼規範才能進行通訊。而 CipherSuites 則定義了 SSL / TLS 安全鏈接中所使用的加密算法的組合，該組合包含三種不一樣的算法：

1. 握手期間所使用的的密鑰交換和認證算法 (最經常使用的是 RSA 算法)
2. 加密算法 (用於握手完成後的對稱加密，經常使用的有 AES、3DES等)
3. 信息摘要算法 (經常使用的有 SHA-25六、SHA-1 和 MD5 等)

四、總結

本文對 SSL / TLS 握手過程進行了詳細的解析，也對握手過程當中的幾個重要概念進行了補充說明。想繼續深刻了解的小夥伴能夠去參考一下 CloudFlare 和 IBM 的官網，這兩個網站也是本文內容的主要來源。多逛逛英文網站，不只能夠漲姿式，獲取權威信息，還能順帶提高一波英語水平，一箭雙鵰，豈不美哉，但願小夥伴們也能儘快養成這樣的好習慣。HTTPS 詳解部分到此結束，我們下篇文章再見。