SSL/TLS算法流程解析

時間 2019-11-26

標籤 ssl tls 算法流程解析欄目 SSL 简体版

原文原文鏈接

SSL/TLS 早已不是陌生的詞彙，然而其原理及細則卻不是太容易記住。本文將試圖經過一些簡單圖示呈現其流程原理，但願讀者有所收穫。html

1、相關版本

Version	Source	Description	Browser Support
SSL v2.0	Vendor Standard (from Netscape Corp.) [SSL2]git	First SSL protocol for which implementations exist	- NS Navigator 1.x/2.x - MS IE 3.x - Lynx/2.8+OpenSSL
SSL v3.0	Expired Internet Draft算法 (from Netscape Corp.) [SSL3]瀏覽器	Revisions to prevent specific security attacks, add non-RSA ciphers and support for certificate chains	- NS Navigator 2.x/3.x/4.x - MS IE 3.x/4.x - Lynx/2.8+OpenSSL
TLS v1.0	Proposed Internet Standard安全 (from IETF) [TLS1]服務器	Revision of SSL 3.0 to update the MAC layer to HMAC, add block padding for block ciphers, message order standardization and more alert messages.	-Lynx/2.8+OpenSSL

SSL全稱爲 Socket Security Layer，TLS全稱爲Transport Layer Security，這二者沒有本質的區別，都是作的傳輸層之上的加密(介於傳輸層及應用層之間)。TLS是後續SSL版本分支的名稱，花費長時間去爭論二者的優劣沒有意義。目前TLS最新版本爲 TLS1.2(也稱爲SSL3.3)session

2、SSL/TLS 解決的問題

信息被竊聽(wiretap)，第三方隨時隨地得到通信內容；併發

SSL/TLS 實現了傳輸信息的加密。dom

數據被篡改(tampering)，第三方可修改傳輸中的數據；性能

SSL/TLS 實現了數據簽名及校驗。

身份被冒充(pretending)，第三方可冒充通信者身份傳輸數據；

SSL/TLS 採用了CA數字證書認證機制。

3、握手階段

簡單點說，SSL/TLS對於傳輸層的加密是經過動態密鑰對數據進行加密實現的，而動態密鑰則經過握手流程協商制定；爲了保證動態密鑰的安全性，其中免不了使用公鑰加密算法(非對稱)、數字證書籤名等技術手段。

一個SSL/TLS 握手過程須要協商的信息包括：

1 協議的版本號；

2 加密算法，包括非對稱加密算法、動態密鑰算法；

3 數字證書，傳輸雙方經過交換證書及簽名校驗對彼此進行鑑權；

4 動態密鑰，傳輸數據過程使用該密鑰進行對稱加解密，該密鑰經過非對稱密鑰進行加密傳輸。

4、流程解析

一個典型的SSL/TLS 握手流程包括雙向認證，以下所示：

1. 客戶端發出一個 client hello 消息，攜帶的信息包括：

所支持的SSL/TLS 版本列表；支持的與加密算法；所支持的數據壓縮方法；隨機數A;

2. 服務端響應一個 server hello 消息，攜帶的信息包括：

協商採用的SSL/TLS 版本號；會話ID；隨機數B；服務端數字證書 serverCA；

因爲雙向認證需求，服務端須要對客戶端進行認證，會同時發送一個 client certificate request，表示請求客戶端的證書；

3. 客戶端校驗服務端的數字證書；校驗經過以後發送隨機數C，該隨機數稱爲pre-master-key，使用數字證書中的公鑰加密後發出；

因爲服務端發起了 client certificate request，客戶端使用私鑰加密一個隨機數 clientRandom隨客戶端的證書 clientCA一併發出；

4. 服務端校驗客戶端的證書，併成功將客戶端加密的隨機數clientRandom 解密；

根據隨機數A/隨機數B/隨機數C(pre-master-key) 產生動態密鑰 master-key，加密一個finish 消息發至客戶端；

5. 客戶端根據一樣的隨機數和算法生成master-key，加密一個finish 消息發送至服務端；

6. 服務端和客戶端分別解密成功，至此握手完成，以後的數據包均採用master-key進行加密傳輸。

5、要點解析

雙向認證和單向認證

雙向認證更好的解決了身份冒充問題，服務端提供證書的同時要求對客戶端身份進行認證；然而在一些常見的應用場景下每每只有單向認證，如採用https網站只須要求客戶端(瀏覽器)對服務端的證書進行認證。

在單向認證場景下，握手階段2服務端不會發出 client certificate request，以後服務端也不須要校驗客戶端證書；

在雙向認證場景下，客戶端若是沒法提供證書，會發出 no digital certificate alert 的警告信息，此時可能致使握手失敗(根據服務端策略而定)；

隨機數的使用

因爲數字證書是靜態的，所以要求使用隨機因素來保證協商密鑰的隨機性；對於RSA 算法來講，pre-master-key自己就是一個隨機數，再加上hello消息中的隨機，三個隨機數經過一個密鑰導出器最終導出一個對稱密鑰。

之因此採用 pre-master-key 機制是由於SSL協議不信任每一個主機都能產生徹底隨機的隨機數，若是 pre-master-key 不隨機，那麼被猜出來的風險就很大，因而僅僅使用 pre-master-secret做爲密鑰不合適，須要引入新的隨機因素，也就是同時結合hello消息中的雙向隨機數。