【計網】SSL/TLS核心原理

序言

在HTTP協議中，信息是明文傳輸的，因此為了通信安全就有了HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)協議。HTTPS也是一種超文本傳送協議，在HTTP的基礎上加入了SSL/TLS協議，SSL/TLS依靠證書來驗證服務端的身份，并為瀏覽器和服務端之間的通信加密。HTTPS是一種通過計算機網絡進行安全通信的傳輸協議，使用HTTP進行通信，借助SSL/TLS建立安全通道和加密數據包。使用HTTPS的主要目的是提供對網站服務端的身份認證，同時保護交換數據的隱私與完整性。TLS是傳輸層加密協議，前身是SSL協議，由網景(Netscape)公司1995年發布，有時候TLS和SSL兩者不做太多區分。

SSL/TLS協議的版本演進

TCP是傳輸層的協議，但是它是明文傳輸的，是不安全的。SSL的誕生給TCP加了一層保險，為TCP通信提供安全及數據完整性保護。TLS只是SSL的升級版，它們的作用是一樣的。TLS（Transport Layer Security，傳輸層安全協議）由兩層組成：TLS記錄(TLS Record)和TLS握手(TLS Handshake)。TLS協議是更新、更安全的SSL協議版本。SSL/TLS可以理解為安全傳輸層協議不同發展階段的版本。1999年，SSL應用廣泛，已經成為互聯網上的事實標準。IETF（Internet Engineering Task Force，國際互聯網工程任務組）在1999年把SSL標準化。完成標準化之后，SSL協議名稱被改為TLS。SSL/TLS位于應用層和傳輸層之間，除了HTTP外，它可以為任何基于TCP傳輸層以上的應用層協議（如WebSocket協議）提供安全性保證。理論上，SSL/TLS協議屬于傳輸層。從理論模型的維度來說，該協議在TCP/IP協議棧的分層結構中所處的層次位置大致如圖12-1所示。但是，在具體的編碼實現上，SSL/TLS協議屬于應用層。從實現的維度來說，該協議在TCP/IP協議棧分層結構中所處的層次位置大致如圖

在這里插入圖片描述
綜合起來可以表述為：SSL/TLS協議理論上屬于傳輸層，卻實現于應用層。

在客戶端瀏覽器中，目前應用最廣泛的是SSL 3.0、TLS 1.0（有時被標為SSL 3.1）?、TLS 1.1（有時被標為SSL3.2）?、TLS 1.2（有時被標為SSL 3.3）四個版本的協議。比如，在IE瀏覽器上，用戶可以設置是否使用SSL/TLS協議，還可以設置支持哪一些版本的協議，具體如圖

在這里插入圖片描述

SSL/TLS協議的分層結構

SSL/TLS協議包括握手協議(Handshake Protocol)、密碼變化協議(SSL Change Cipher Spec Protocol)、警告協議(Alert Protocol)、記錄協議(Record Protocol)。

(1)握手協議：SSL/TLS協議非常重要的組成部分，用來協商通信過程中使用的加密套件（加密算法、密鑰交換算法和MAC算法等）?、在服務端和客戶端之間安全地交換密鑰、實現服務端和客戶端的身份驗證。

(2)密碼變化協議：客戶端和服務端通過密碼變化協議通知對端，隨后的報文都將使用新協商的加密套件和密鑰進行保護和傳輸。

(3)警告協議：用來向對端發送告警信息，消息中包含告警的嚴重級別和描述。

(4)應用數據協議：負責將SSL/TLS承載的應用數據傳達給通信對端。

(5)記錄協議：主要負責對上層的數據（SSL/TLS握手協議、SSL/TLS密碼變化協議、SSL/TLS警告協議和應用數據協議）進行分塊計算、添加MAC值、加密等處理，并把處理后的記錄塊傳輸給對端。

在這里插入圖片描述

SSL/TLS協議主要分為兩層（上層的是握手協議、密碼變化協議、警告協議和應用數據協議，下層的是記錄協議）?，主要負責使用對稱密碼對消息進行加密。其中，握手協議(Handshake Protocol)是SSL/TSL通信中最復雜的子協議，也是安全通信所涉及的第一個子協議。

SSL/TLS運行過程

SSL/TLS協議實現通信安全的基本思路是：消息發送之前，發送方A先向接收方B申請公鑰，發送方A采用公鑰加密法對發出去的通信內容進行加密，接收方B收到密文后，用自己的私鑰對通信密文進行解密。

(1)客戶端向服務端索要并驗證公鑰。（公鑰加密，私鑰解密驗證）
(2)雙方協商生成“對話密鑰”?。
(3)雙方采用“對話密鑰”進行加密通信。

前兩步又稱為“握手階段”?，每一個TLS連接都會以握手開始。?“握手階段”涉及四次通信，并且所有通信都是明文的。在握手過程中，客戶端和服務端將進行以下四個主要階段：

(1)交換各自支持的加密套件和參數，經過協商后，雙方就加密套件和參數達成一致。
(2)驗證對方（主要指服務端）的證書，或使用其他方式進行服務端身份驗證。
(3)對將用于保護會話的共享主密鑰達成一致。
(4)驗證握手消息是否被第三方修改。

SSL/TLS第一階段握手

客戶端與服務端通過TCP三次握手建立傳輸層連接后，通信雙方需要交換各自支持的加密套件和參數，經過協商后，使通信雙方的加密套件和參數達成一致。

SSL/TLS“握手”第一個階段的工作為：由客戶端發一個Client Hello報文給服務端，并且第一個階段只有這一個數據幀（報文）?。Client Hello數據幀的內容大致包括以下信息：

(1)客戶端支持的SSL/TLS協議版本，比如TLS 1.2版。
(2)一個客戶端生成的隨機數，這是握手過程中的第一個隨機數，稱之為Random_C。
(3)客戶端支持的簽名算法、加密方法、摘要算法（比如RSA公鑰簽名算法）?。
(4)客戶端支持的壓縮方法。

SSL/TLS第二階段握手

SSL/TLS握手第二個階段的工作為：服務端對客戶端的Client Hello請求進行響應。在收到客戶端請求(ClientHello)后，服務端向客戶端發出回應，這個階段的服務端回應幀（報文）一般包含4個回復幀：Server Hello幀、Certificate幀、Server Key Exchange幀、Server Hello Done幀。

Server Hello幀

服務端回復的Server Hello幀主要包含以下內容：
(1)回復服務端使用的加密通信協議版本，比如TLS 1.2版本。
(2)一個服務端生成的隨機數，是整個握手過程中的第二個隨機數，記為“Random_S”?，稍后用于生成“對話密鑰”?。
(3)確認使用的加密方法，比如RSA公鑰加密。
(4)服務端的證書。

Certificate幀

Certificate幀用于返回服務端證書，該證書中含有服務端的證書清單（包括服務端公鑰）?，用于身份驗證和密鑰協商。在多數電子商務應用中，客戶端都需要進行服務端身份驗證，服務端通過Certificate幀發送自己的證書給客戶端。

服務端通過Certificate幀給客戶端提供身份信息，那么客戶端是否需要提供自己的身份證書給服務端呢？

雖然大部分場景中服務端不需要驗證客戶端的身份，但是只要服務端需要驗證客戶端的身份，服務端就會發一個CertificateRequest證書請求給客戶端。比如，在一些安全性要求較高的機構（如金融機構）往往需要驗證客戶端身份證書，這些機構只允許通過認證客戶連入自己的網絡，并且會給正式客戶提供USB密鑰，里面就包含了一張客戶端身份證書，在通信握手時要求客戶端提供證書。

Server Key Exchange幀

Server Key Exchange幀的目的是攜帶密鑰交換的額外數據，其消息內容對于不同的協商算法套件都會存在差異。

在某些場景中，服務端不需要發送Server Key Exchange握手消息。如果在Server Hello消息中使用DHE/ECDHE非對稱密鑰協商算法來進行SSL握手，就將發送該類型握手消息。對于使用RSA算法的SSL握手，不會發送該類型握手消息。另外，使用DH、ECDH算法進行握手時也不會發送該類型握手消息。

Server Hello Done幀

Server Hello Done幀是第二階段的最后一幀，標記服務端對客戶端的Client Hello請求幀的所有響應報文發送完畢，Server Hello Done幀的長度為0。

客戶端收到服務端證書后，進行驗證，如果證書不是可信機構頒發的，或者域名不一致，或者證書已經過期，那么客戶端會進行警告；如果證書沒有問題，就繼續進行通信。

SSL/TLS第三階段握手

SSL/TLS握手(Handshake)第三個階段的工作為：客戶端進行回應。在這個階段，客戶端會發送Client KeyExchange、Change Cipher Spec、Encrypted Handshake三個數據幀。

客戶端收到第二個階段的服務端回應報文以后，首先驗證服務端證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。

如果證書沒有問題，客戶端就會從證書中取出服務端的公鑰，然后向服務端發送三項信息：

(1)一個隨機數。該隨機數用服務端公鑰加密，防止被第三方竊聽。

此隨機數是整個握手階段出現的第三個隨機數，又稱Pre-master key。有了它以后，客戶端和服務端就同時有了三個隨機數，接著雙方用事先商定的加密方法各自生成本次會話所用的同一把“會話密鑰”?。

(2)編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰加密后發送。

(3)客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的哈希值，用來供服務端校驗。

服務端的證書信息會包含Public Key（公鑰）?，稍后客戶端進行證書驗證（身份驗證）的流程大致為：Client隨機生成一串數，然后用Server發送的Public Key加密（RSA算法）后發給Server；而Server會用其對應的Private key（私鑰）解密后再返回給Client; Client將其與原文比較，如果一致，則說明Server擁有Private key，與自己通信的對端Server正是證書的擁有者，因為Public key加密的數據只有Private key才能解密。在實際通信過程中，這個認證過程會復雜很多，包含多次哈希、偽隨機等復雜運算。