SSL協議原理

SSL（Security Socket Layer）是一個安全協議，為基于TCP的應用層協議提供安全連接，SSL介于TCP/IP協議堆疊第四層和第七層之間，SSL可以為HTTP協議提供安全例案件，SSL為網路上資料的傳輸提供安全性保障，

SSL協議結構

SSL協議結構分為兩層：

• 底層為SSL記錄協議（SSL record protocol）

  • 主要負責對上層資料進行分塊、壓縮、計算并添加MAC（Message Authenticate Code ，散列演算法計算訊息認證代碼）、加密，最后把記錄塊傳輸給對方

• 上層：SSL握手協議（SSLhandshake protocol）、SSL密碼變化協議（SSL change cipher spec protocol）、SSL警告協議（SSL alert protocol）

  • SSL握手協議:客戶端和服務器通過握手協議建立一個會話，會話包含一組引數，主要有會話ID、對方的證書、加密演算法串列(包括密鑰交換演算法、資料加密演算法和MAC演算法)、壓縮演算法以及主密鑰，SSL會話可以被多個連接共享，以減少會話協商開銷，
  • SSL密碼變化協議:客戶端和服務器端通過密碼變化協議通知接收方，隨后的報文都將使用新協商的加密演算法串列和密鑰進行保護和傳輸，
  • SSL警告協議:用來允許一方向另一方報告告警資訊，訊息中包含告警的嚴重級別和描述，

SSL原理（握手協議）

通過SSL握手協議協商資料傳輸中要用到的相關安全引數，并對對端的身份進行驗證，

SSL握手協議第一階段

客戶端發送一個ClientHello訊息，包含引數：

• 版本:訊息中協議版本是兩個byte長度分別表示主次版本，目前SSL擁有的版本有SSLv1、SSLv2、 SSLv3以及TSLv1 (即SSLv3.1 )，
• 亂數: 32位時間戳+28位元組隨機序列，用于在后面計算所有訊息的摘要或計算主密鑰，
• 會話ID: SSL會 話ID標識一次會話用，可以重用，
• 客戶端支持的密碼演算法串列( CipherSuite) :密鑰套件串列，串列中包含了Client端支持的所有密鑰套件，
• 客戶端支持的壓縮方法串列:客戶端支持的壓縮演算法串列，填0表示空，

當服務器收到包含以上資訊的ClientHello訊息后，服務器發送ServerHello訊息，包括引數：

• 版本:服務器拿出ClientHello訊息中的版本號，再看看自己支持的版本串列，選擇兩者都支持的最高版本號定為這次協商出來的SSL協議使用的版本，
• 服務器產生的亂數:此處產生的亂數與ClientHello訊息中的類似，
• 會話ID:服務器端檢測到傳過來的Session ID 是慷訓者檢索Session串列沒有發現傳過來的Session ID就會新建一個，

服務器從客戶端建議的密碼演算法中挑出一套（CipherSuite）密碼演算法

服務器從客戶端建議的壓縮方法中挑出一個壓縮演算法

客戶端Client Hello資料包

服務端server Hello資料包

SSL握手協議第二階段

Certificate訊息( 可選)

一般情況下，除了會話恢復時不需要發送該訊息，在SSL握手的全流程中，都需要包含該訊息，訊息包含一個X.509證書，證書中包含公鑰，發給客戶端用來驗證簽名或在密鑰交換的時候給訊息加密，

服務端將自己的證書下發給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過后取出證書中的公鑰，

Server Key Exchange (可選)

根據之前在ClientHello訊息中包含的CipherSuite資訊，決定了密鑰交換方式(例如RSA或者DH)，因此在Server Key Exchange消 息中便會包含完成密鑰交換所需的一系列引數，

Certificate Request (可選)

服務器端發出CertificateRequest訊息，要求客戶端發他自己的證書過來進行驗證，該訊息中包含服務器端支持的證書型別(RSA、DSA、ECDSA等)和服務器端所信任的所有證書發行機構的CA串列，客戶端會用這些資訊來篩選證書，

ServerHello Done

該訊息表示服務器已經將所有資訊發送完畢，接下來等待客戶端的訊息，

Certificate訊息資料包

Server Key Exchange訊息資料包

在Diffie-Hellman中，客戶端無法自行計算預主密鑰; 雙方都有助于計算它，因此客戶端需要從服務器獲取Diffie-Hellman公鑰，

由上圖可知，此時密鑰交換也由簽名保護，

ServerHello Done資料包

SSL握手協議第三階段

Certificate ( 可選)

如果在第二階段服務器端要求發送客戶端證書，客戶端便會在該階段將自己的證書發送過去，服務器端在之前發送的Certificate Request訊息中包含了服務器端所支持的證書型別和CA串列，因此客戶端會在自己的證書中選擇滿足這兩個條件的第一個證書發送過去，若客戶端沒有證書，則發送一個no_ certificate警告 ，

Client Key exchange

根據之前從服務器端收到的亂數，按照不同的密鑰交換演算法，算出一一個pre-master，發送給服務器，服務器端收到pre-master算出main master.而客戶端當然也能自己通過pre-master算出main master.如此以來雙方就算出了對稱密鑰，

Certificate verify (可選)

只有在客戶端發送了自己證書到服務器端，這個訊息才需要發送，其中包含一個簽名，對從第一條訊息以來的所有握手訊息的HMAC值(用master_ secret) 進行簽名，

Client Key exchange資料包

SSL握手協議第四階段

建立起一個安全的連接，客戶端發送一個Change Cipher Spec訊息，并且把協商得到的CipherSuite拷貝到當前連接的狀態之中，然后，客戶端用新的演算法、密鑰引數發送一個Finished訊息，這條訊息可以檢查密鑰交換和認證程序是否已經成功，其中包括一個校驗值，對客戶端整個握手程序的訊息進行校驗，服務器同樣發送Change Cipher Spec訊息和Finished訊息，握手程序完成，客戶端和服務器可以交換應用層資料進行通信，

Server Finished:
服務端握手結束通知，

使用私鑰解密加密的Pre-master資料，基于之前(Client Hello 和 Server Hello)交換的兩個明文亂數 random_C 和 random_S，計算得到協商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
計算之前所有接收資訊的 hash 值，然后解密客戶端發送的 encrypted_handshake_message，驗證資料和密鑰正確性;
發送一個 ChangeCipherSpec（告知客戶端已經切換到協商過的加密套件狀態，準備使用加密套件和 Session Secret加密資料了）
服務端也會使用 Session Secret 加密一段 Finish 訊息發送給客戶端，以驗證之前通過握手建立起來的加解密通道是否成功，

SSL會話恢復

會話恢復是指只要客戶端和服務器已經通信過一次，它們就可以通過會話恢復的方式來跳過整個握手階段而直接進行資料傳輸，

SSL采用會話恢復的方式來減少SSL握手程序中造成的巨大開銷，

此功能從原來正常協調的13步，減少到只需要6步，大大減少了SSL VPN隧道建立所需要的開銷，

為了加快建立握手的速度，減少協議帶來的性能降低和資源消耗(具體分析在后文)，TLS 協議有兩類會話快取機制：

會話標識 session ID: 由服務器端支持，協議中的標準欄位，因此基本所有服務器都支持，服務器端保存會話ID以及協商的通信資訊，Nginx 中1M 記憶體約可以保存4000個 session ID 機器相關資訊，占用服務器資源較多;

會話記錄 session ticket :需要服務器和客戶端都支持，屬于一個擴展欄位，支持范圍約60%(無可靠統計與來源)，將協商的通信資訊加密之后發送給客戶端保存，密鑰只有服務器知道，占用服務器資源很少，

二者對比，主要是保存協商資訊的位置與方式不同，類似與 http 中的 session 與 cookie，二者都存在的情況下，(nginx 實作)優先使用 session_ticket，

會話恢復具體程序（Session ID機制）：

1.如果客戶端和服務器之間曾經建立了連接，服務器會在握手成功后回傳 session ID，并保存對應的通信引數在服務器中;

2.如果客戶端再次需要和該服務器建立連接，則在 client_hello 中 session ID 中攜帶記錄的資訊，發送給服務器;

3.服務器根據收到的 session ID 檢索快取記錄，如果沒有檢索到貨快取過期，則按照正常的握手程序進行;

4.如果檢索到對應的快取記錄，則回傳 change_cipher_spec與 encrypted_handshake_message 資訊，兩個資訊作用類似，encrypted_handshake_message 是到當前的通信引數與 master_secret的hash 值;

5.如果客戶端能夠驗證通過服務器加密資料，則客戶端同樣發送 change_cipher_spec 與 encrypted_handshake_message 資訊;
服務器驗證資料通過，則握手建立成功，開始進行正常的加密資料通信，

會話恢復具體程序（ session ticket）：

1.如果客戶端和服務器之間曾經建立了連接，服務器會在 new_session_ticket 資料中攜帶加密的 session_ticket 資訊，客戶端保存;

2.如果客戶端再次需要和該服務器建立連接，則在 client_hello 中擴展欄位 session_ticket 中攜帶加密資訊，一起發送給服務器;

3.服務器解密 sesssion_ticket 資料，如果能夠解密失敗，則按照正常的握手程序進行;

4.如果解密成功，則回傳 change_cipher_spec 與 encrypted_handshake_message 資訊，兩個資訊作用與 session ID 中類似;

5.如果客戶端能夠驗證通過服務器加密資料，則客戶端同樣發送 change_cipher_spec與encrypted_handshake_message 資訊;

6.服務器驗證資料通過，則握手建立成功，開始進行正常的加密資料通信，

SSL原理（記錄協議）

SSL記錄協議主要用來實作對資料塊的分塊、加密解密、壓縮與解壓縮、完整性檢查及封裝各種高層協議，

每個SSL記錄包含以下資訊:

• 內容型別
• 協議版本號，目前有2.0和3.0版本
• 記錄資料的長度
• 資料有效載荷
• 散列演算法計算訊息認證代碼

詳細步驟

(1)將上層分下來的資料包分成合適的資料塊，但是每個資料塊不得超過214位元組，

(2)對每個資料塊進行壓縮，但是不能丟失資料資訊，

(3)計算壓縮后的資料訊息認證碼MAC，并添加在壓縮包后，添加后總長度不得超過2262位元組，

(4)對于流加密，壓縮保額和MAC以前被加密，對于分組加密，在MAC之后，加密之前可以增加填充，填充由表示填充長度的位元組和移動數目的填充位元組組成，填充位元組的數目使得要加密的資料的總長度成為加密分組長度整數倍的最小數目，

(5)給SSL添加一個首部，其中包括:內容型別、主要版本、次要版本、壓縮長度等
資訊，

通過以上程序把原始的資料加密為SSL協議的記錄集，