SSL/TLS演算法流程解析

標籤：sha   授權   digital   原理   pre   需求   vendor   常用   png   

 

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

 

一、相關版本

Version	Source	Description	Browser Support
SSL v2.0	Vendor Standard  (from Netscape Corp.) [SSL2]	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)

 

二、SSL/TLS 解決的問題

資訊被竊聽(wiretap)，第三方隨時隨地獲得通訊內容；

    SSL/TLS 實現了傳輸資訊的加密。

資料被篡改(tampering)，第三方可修改傳輸中的資料；

    SSL/TLS 實現了資料簽名及校正。

身份被冒充(pretending)，第三方可冒充通訊者身份傳輸資料；

    SSL/TLS 採用了CA數位憑證認證機制。

 

三、握手階段

簡單點說，SSL/TLS對於傳輸層的加密是通過動態金鑰組資料進行加密實現的，而動態密鑰則通過握手流程協商制定；為了保證動態密鑰的安全性，其中免不了使用公開金鑰加密演算法(非對稱)、數位憑證簽名等技術手段。

一個SSL/TLS 握手過程需要協商的資訊包括：

 1 協議的版本號碼；

 2 密碼編譯演算法，包括非對稱式加密演算法、動態密鑰演算法；

 3 數位憑證，傳輸雙方通過交換認證及簽名校正對彼此進行鑒權；

 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進行加密傳輸。

 

五、要點解析雙向認證和單向認證

雙向認證更好的解決了身份冒充問題，服務端提供認證的同時要求對用戶端身份進行認證；然而在一些常見的應用情境下往往只有單向認證，如採用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訊息中的雙向隨機數。

 

工作階段金鑰重用

SSL/TLS握手過程比較繁瑣，同時非對稱加解密效能比對稱金鑰要差得多；如果每次重建串連時都需要進行一次握手會產生較大開銷，因此有必要實現會話的重用以提高效能。

常用的方式包括：

SessionID(RFC 5246)，用戶端和服務端同時維護一個會話ID和會話資料狀態；重建串連時雙方根據sessionID找到之前的工作階段金鑰實現重用；

SessionTicket(RFC 5077)，由服務端根據工作階段狀態產生一個加密的ticket，並將key也發給用戶端保證兩端都可以對其進行解密。該機制相較sessionID的方式更加輕量級，服務端不需要儲存工作階段狀態資料，可減輕一定壓力。

 

認證的校正

1. 檢查數位簽章；

   數位簽章通過數字摘要演算法產生並通過私密金鑰加密傳輸，對端公開金鑰解密；

2. CA鏈授權檢查；

3. 認證到期及啟用時間檢查；

 

數字摘要的計算圖示

 

關於Server Name Indication

在普通 SSL/TLS握手的過程中，用戶端發送的資訊之中不包括伺服器的網域名稱；因此理論上伺服器只能包含一個網域名稱，否則會分不清應該向用戶端提供哪一個網域名稱的數位憑證。在後續TLS的版本中實現了SNI(Server Name Indication) 擴充，用於支援一台伺服器主機需服務多個網域名稱的情境。

由用戶端請求時發送指定的網域名稱，伺服器據此選擇相應認證完成握手。

 

六、參考文檔

阮一峰_SSL/TLS協議運行機制的概述

An overview of the SSL or TLS handshake

 

SSL/TLS演算法流程解析