一、簡介

SSL，全稱Secure Socket Layer，為Netscape所研發，用以保障在Internet上數據傳輸之安全。
SSL利用數據加密、身份驗證和消息完整性驗證機制，為網絡上數據的傳輸提供安全性保證。SSL支持各種應用層協議。由于SSL位于應用層和傳輸層之間，所以可以為任何基于TCP等可靠連接的應用層協議提供安全性保證。

二、SSL安全機制

1.身份驗證機制

基于證書利用數字簽名方法對服務器和客戶端進行身份驗證，其中客戶端的身份驗證是可選的。

2.數據傳輸的機密性

利用對稱密鑰算法對傳輸的數據進行加密。

3.消息完整性驗證

消息傳輸過程中使用MAC算法來檢驗消息的完整性。

三、SSL實現原理

1.身份驗證機制

SSL利用數字簽名來驗證通信對端的身份。

非對稱密鑰算法可以用來實現數字簽名。由于通過私鑰加密后的數據只能利用對應的公鑰進行解密，因此根據解密是否成功，就可以判斷發送者的身份，如同發送者對數據進行了“簽名”。

例如，Alice使用自己的私鑰對一段固定的信息加密后發給Bob，Bob利用Alice的公鑰解密，如果解密結果與固定信息相同，那么就能夠確認信息的發送者為Alice，這個過程就稱為數字簽名。

使用數字簽名驗證身份時，需要確保被驗證者的公鑰是真實的，否則，非法用戶可能會冒充被驗證者與驗證者通信。如下圖所示，Cindy冒充Bob，將自己的公鑰發給Alice，并利用自己的私鑰計算出簽名發送給Alice，Alice利用“Bob”的公鑰（實際上為Cindy的公鑰）成功驗證該簽名，則Alice認為Bob的身份驗證成功，而實際上與Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的機制保證公鑰的真實性。

身份驗證.png

2.數據傳輸的機密性

SSL加密通道上的數據加解密使用對稱密鑰算法，目前主要支持的算法有DES、3DES、AES等，這些算法都可以有效地防止交互數據被破解。

對稱密鑰算法要求解密密鑰和加密密鑰完全一致。因此，利用對稱密鑰算法加密傳輸數據之前，需要在通信兩端部署相同的密鑰。

3. 消息完整性驗證

為了避免網絡中傳輸的數據被非法篡改，SSL利用基于MD5或SHA的MAC算法來保證消息的完整性。

MAC算法是在密鑰參與下的數據摘要算法，能將密鑰和任意長度的數據轉換為固定長度的數據。利用MAC算法驗證消息完整性的過程如下圖所示。

發送者在密鑰的參與下，利用MAC算法計算出消息的MAC值，并將其加在消息之后發送給接收者。接收者利用同樣的密鑰和MAC算法計算出消息的MAC值，并與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改，接收者將丟棄該報文。

消息完整性驗證.png

MAC算法要求通信雙方具有相同的密鑰，否則MAC值驗證將會失敗。因此，利用MAC算法驗證消息完整性之前，需要在通信兩端部署相同的密鑰。

4.利用非對稱密鑰算法保證密鑰本身的安全

對稱密鑰算法和MAC算法要求通信雙方具有相同的密鑰，否則解密或MAC值驗證將失敗。因此，要建立加密通道或驗證消息完整性，必須先在通信雙方部署一致的密鑰。

SSL利用非對稱密鑰算法加密密鑰的方法實現密鑰交換，保證第三方無法獲取該密鑰。如下圖所示，SSL客戶端（如Web瀏覽器）利用SSL服務器（如Web服務器）的公鑰加密密鑰，將加密后的密鑰發送給SSL服務器，只有擁有對應私鑰的SSL服務器才能從密文中獲取原始的密鑰。SSL通常采用RSA算法加密傳輸密鑰。（Server端公鑰加密密鑰，私鑰解密密鑰）

利用非對稱密鑰算法保證密鑰本身的安全.png

實際上，SSL客戶端發送給SSL服務器的密鑰不能直接用來加密數據或計算MAC值，該密鑰是用來計算對稱密鑰和MAC密鑰的信息，稱為premaster secret。

SSL客戶端和SSL服務器利用premaster secret計算出相同的主密鑰（master secret），再利用master secret生成用于對稱密鑰算法、MAC算法等的密鑰。

premaster secret是計算對稱密鑰、MAC算法密鑰的關鍵。

5.利用PKI保證公鑰的真實性

PKI通過數字證書來發布用戶的公鑰，并提供了驗證公鑰真實性的機制。數字證書（簡稱證書）是一個包含用戶的公鑰及其身份信息的文件，證明了用戶與公鑰的關聯。數字證書由權威機構——CA簽發，并由CA保證數字證書的真實性。

SSL客戶端把密鑰加密傳遞給SSL服務器之前，SSL服務器需要將從CA獲取的證書發送給SSL客戶端，SSL客戶端通過PKI判斷該證書的真實性。如果該證書確實屬于SSL服務器，則利用該證書中的公鑰加密密鑰，發送給SSL服務器。
驗證SSL服務器/SSL客戶端的身份之前，SSL服務器/SSL客戶端需要將從CA獲取的證書發送給對端，對端通過PKI判斷該證書的真實性。如果該證書確實屬于SSL服務器/SSL客戶端，則對端利用該證書中的公鑰驗證SSL服務器/SSL客戶端的身份。

四、SSL協議基本運行過程

1.分層結構

SSL位于應用層和傳輸層之間，它可以為任何基于TCP等可靠連接的應用層協議提供安全性保證。SSL協議本身分為兩層：

• 上層為SSL握手協議（SSL handshake protocol）、SSL密碼變化協議（SSL change cipher spec protocol）和SSL警告協議（SSL alert protocol）；
• 底層為SSL記錄協議（SSL record protocol）。

SSL協議分層結構.png

其中：

• SSL握手協議：是SSL協議非常重要的組成部分，用來協商通信過程中使用的加密套件（加密算法、密鑰交換算法和MAC算法等）、在服務器和客戶端之間安全地交換密鑰、實現服務器和客戶端的身份驗證。
• SSL密碼變化協議：客戶端和服務器端通過密碼變化協議通知對端，隨后的報文都將使用新協商的加密套件和密鑰進行保護和傳輸。
• SSL警告協議：用來向通信對端報告告警信息，消息中包含告警的嚴重級別和描述。
• SSL記錄協議：主要負責對上層的數據（SSL握手協議、SSL密碼變化協議、SSL警告協議和應用層協議報文）進行分塊、計算并添加MAC值、加密，并把處理后的記錄塊傳輸給對端。

2.基本運行過程

• 客戶端向服務器端索要并驗證公鑰。
• 雙方協商生成"對話密鑰"。
• 雙方采用"對話密鑰"進行加密通信。
  其中，前兩個階段，被稱為“握手階段”。

五、握手階段詳細過程

"握手階段"涉及四次通信，該階段的所有通信都是明文的。

1.客戶端發出請求（ClientHello）

• 支持的協議版本，比如TLS 1.0版。
• 一個客戶端生成的隨機數，稍后用于生成"對話密鑰"。
• 支持的加密方法，比如RSA公鑰加密。
• 支持的壓縮方法。

2.服務器回應（SeverHello）

• 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
• 一個服務器生成的隨機數，稍后用于生成"對話密鑰"。
• 確認使用的加密方法，比如RSA公鑰加密。
• 服務器證書。

除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

3.客戶端回應

客戶端收到服務器回應以后，首先驗證服務器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然后，向服務器發送下面三項信息。

• 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。
• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
• 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。

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

4.服務器的最后回應

服務器收到客戶端的第三個隨機數pre-master key之后，計算生成本次會話所用的"會話密鑰"。然后，向客戶端最后發送下面信息。

• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
• 服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。

至此，整個握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。

六、問題

1.SSL/TLS協議的基本思路

SSL/TLS協議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。

2.公鑰加密計算量太大，如何減少耗用的時間？

每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運算速度非?？?，而服務器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

3.為什么一定要用三個隨機數，來生成"會話密鑰"？

"不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由于SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。pre master的存在在于SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"