- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- BOB登陆 人才研學中心
- 關於我們
SSL技術白皮書
關鍵詞：SSL，PKI，MAC
摘 要：SSL利用數據加密、身份驗證和消息完整性驗證機製，為基於TCP等可靠連接的應用層協議提供安全性保證。本文介紹了SSL的產生背景、安全機製、工作過程及典型組網應用。
縮略語：
縮略語 | 英文全名 | 中文解釋 |
AES | Advanced Encryption Standard | 高級加密標準 |
CA | Certificate Authority | 證書機構 |
DES | Data Encryption Standard | 數據加密標準 |
HTTPS | Hypertext Transfer Protocol Secure | 安全超文本傳輸協議 |
MAC | Message Authentication Code | 消息驗證碼 |
MD5 | Message Digest 5 | 消息摘要算法5 |
PKI | Public Key Infrastructure | 公鑰基礎設施 |
RSA | Rivest Shamir and Adleman | 非對稱密鑰算法的一種 |
SHA | Secure Hash Algorithm | 安全散列算法 |
SSL | Secure Sockets Layer | 安全套接層 |
VPN | Virtual Private Network | 虛擬專有網絡 |
目 錄
基於萬維網的電子商務和網上銀行等新興應用，極大地方便了人們的日常生活，受到人們的青睞。由於這些應用都需要在網絡上進行在線交易，它們對網絡通信的安全性提出了更高的要求。傳統的萬維網協議HTTP不具備安全機製——采用明文的形式傳輸數據、不能驗證通信雙方的身份、無法防止傳輸的數據被篡改等，導致HTTP無法滿足電子商務和網上銀行等應用的安全性要求。
Netscape公司提出的安全協議SSL，利用數據加密、身份驗證和消息完整性驗證機製，為網絡上數據的傳輸提供安全性保證。SSL可以為HTTP提供安全連接，從而很大程度上改善了萬維網的安全性問題。
SSL具有如下優點：
l 提供較高的安全性保證。SSL利用數據加密、身份驗證和消息完整性驗證機製，保證網絡上數據傳輸的安全性。
l 支持各種應用層協議。雖然SSL設計的初衷是為了解決萬維網安全性問題，但是由於SSL位於應用層和傳輸層之間，它可以為任何基於TCP等可靠連接的應用層協議提供安全性保證。
l 部署簡單。目前SSL已經成為網絡中用來鑒別網站和網頁瀏覽者身份，在瀏覽器使用者及Web服務器之間進行加密通信的全球化標準。SSL協議已被集成到大部分的瀏覽器中，如IE、Netscape、Firefox等。這就意味著幾乎任意一台裝有瀏覽器的計算機都支持SSL連接，不需要安裝額外的客戶端軟件。
SSL協議實現的安全機製包括：
l 數據傳輸的機密性：利用對稱密鑰算法對傳輸的數據進行加密。
l 身份驗證機製：基於證書利用數字簽名方法對服務器和客戶端進行身份驗證，其中客戶端的身份驗證是可選的。
l 消息完整性驗證：消息傳輸過程中使用MAC算法來檢驗消息的完整性。
網絡上傳輸的數據很容易被非法用戶竊取，SSL采用在通信雙方之間建立加密通道的方法保證數據傳輸的機密性。
所謂加密通道，是指發送方在發送數據前，使用加密算法和加密密鑰對數據進行加密，然後將數據發送給對方；接收方接收到數據後，利用解密算法和解密密鑰從密文中獲取明文。沒有解密密鑰的第三方，無法將密文恢複為明文，從而保證數據傳輸的機密性。
加解密算法分為兩類：
l 對稱密鑰算法：數據加密和解密時使用相同的密鑰。
l 非對稱密鑰算法：數據加密和解密時使用不同的密鑰，一個是公開的公鑰，一個是由用戶秘密保存的私鑰。利用公鑰（或私鑰）加密的數據隻能用相應的私鑰（或公鑰）才能解密。
與非對稱密鑰算法相比，對稱密鑰算法具有計算速度快的優點，通常用於對大量信息進行加密（如對所有報文加密）；而非對稱密鑰算法，一般用於數字簽名和對較少的信息進行加密。
SSL加密通道上的數據加解密使用對稱密鑰算法，目前主要支持的算法有DES、3DES、AES等，這些算法都可以有效地防止交互數據被竊聽。
對稱密鑰算法要求解密密鑰和加密密鑰完全一致。因此，利用對稱密鑰算法加密傳輸數據之前，需要在通信兩端部署相同的密鑰。對稱密鑰的部署方法請參見“2.4 利用非對稱密鑰算法保證密鑰本身的安全”。
電子商務和網上銀行等應用中必須保證要登錄的Web服務器是真實的，以免重要信息被非法竊取。SSL利用數字簽名來驗證通信對端的身份。
非對稱密鑰算法可以用來實現數字簽名。由於通過私鑰加密後的數據隻能利用對應的公鑰進行解密，因此根據解密是否成功，就可以判斷發送者的身份，如同發送者對數據進行了“簽名”。例如，Alice使用自己的私鑰對一段固定的信息加密後發給Bob，Bob利用Alice的公鑰解密，如果解密結果與固定信息相同，那麼就能夠確認信息的發送者為Alice，這個過程就稱為數字簽名。
SSL客戶端必須驗證SSL服務器的身份，SSL服務器是否驗證SSL客戶端的身份，則由SSL服務器決定。SSL客戶端和SSL服務器的身份驗證過程，請參見“3.2 SSL握手過程”。
使用數字簽名驗證身份時，需要確保被驗證者的公鑰是真實的，否則，非法用戶可能會冒充被驗證者與驗證者通信。如圖1所示，Cindy冒充Bob，將自己的公鑰發給Alice，並利用自己的私鑰計算出簽名發送給Alice，Alice利用“Bob”的公鑰（實際上為Cindy的公鑰）成功驗證該簽名，則Alice認為Bob的身份驗證成功，而實際上與Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的機製保證公鑰的真實性，詳細介紹請參見“2.5 利用PKI保證公鑰的真實性”。
圖1 偽造公鑰
為了避免網絡中傳輸的數據被非法篡改，SSL利用基於MD5或SHA的MAC算法來保證消息的完整性。
MAC算法是在密鑰參與下的數據摘要算法，能將密鑰和任意長度的數據轉換為固定長度的數據。利用MAC算法驗證消息完整性的過程如圖2所示。發送者在密鑰的參與下，利用MAC算法計算出消息的MAC值，並將其加在消息之後發送給接收者。接收者利用同樣的密鑰和MAC算法計算出消息的MAC值，並與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改，接收者將丟棄該報文。
圖2 MAC算法示意圖
MAC算法具有如下特征，使其能夠用來驗證消息的完整性：
l 消息的任何改變，都會引起輸出的固定長度數據產生變化。通過比較MAC值，可以保證接收者能夠發現消息的改變。
l MAC算法需要密鑰的參與，因此沒有密鑰的非法用戶在改變消息的內容後，無法添加正確的MAC值，從而保證非法用戶無法隨意修改消息內容。
MAC算法要求通信雙方具有相同的密鑰，否則MAC值驗證將會失敗。因此，利用MAC算法驗證消息完整性之前，需要在通信兩端部署相同的密鑰。MAC密鑰的部署方法請參見“2.4 利用非對稱密鑰算法保證密鑰本身的安全”。
對稱密鑰算法和MAC算法要求通信雙方具有相同的密鑰，否則解密或MAC值驗證將失敗。因此，要建立加密通道或驗證消息完整性，必須先在通信雙方部署一致的密鑰。
SSL利用非對稱密鑰算法加密密鑰的方法實現密鑰交換，保證第三方無法獲取該密鑰。如圖3所示，SSL客戶端（如Web瀏覽器）利用SSL服務器（如Web服務器）的公鑰加密密鑰，將加密後的密鑰發送給SSL服務器，隻有擁有對應私鑰的SSL服務器才能從密文中獲取原始的密鑰。SSL通常采用RSA算法加密傳輸密鑰。
l 實際上，SSL客戶端發送給SSL服務器的密鑰不能直接用來加密數據或計算MAC值，該密鑰是用來計算對稱密鑰和MAC密鑰的信息，稱為premaster secret。SSL客戶端和SSL服務器利用premaster secret計算出相同的主密鑰（master secret），再利用master secret生成用於對稱密鑰算法、MAC算法等的密鑰。premaster secret是計算對稱密鑰、MAC算法密鑰的關鍵。
l 用來實現密鑰交換的算法稱為密鑰交換算法。非對稱密鑰算法RSA用於密鑰交換時，也可以稱之為密鑰交換算法。
利用非對稱密鑰算法加密密鑰之前，發送者需要獲取接收者的公鑰，並保證該公鑰確實屬於接收者，否則，密鑰可能會被非法用戶竊取。如圖1所示，Cindy冒充Bob，將自己的公鑰發給Alice，Alice利用Cindy的公鑰加密發送給Bob的數據，Bob由於沒有對應的私鑰無法解密該數據，而Cindy截取數據後，可以利用自己的私鑰解密該數據。SSL利用PKI提供的機製保證公鑰的真實性，詳細介紹請參見“2.5 利用PKI保證公鑰的真實性”。
PKI通過數字證書來發布用戶的公鑰，並提供了驗證公鑰真實性的機製。數字證書（簡稱證書）是一個包含用戶的公鑰及其身份信息的文件，證明了用戶與公鑰的關聯。數字證書由權威機構——CA簽發，並由CA保證數字證書的真實性。
SSL客戶端把密鑰加密傳遞給SSL服務器之前，SSL服務器需要將從CA獲取的證書發送給SSL客戶端，SSL客戶端通過PKI判斷該證書的真實性。如果該證書確實屬於SSL服務器，則利用該證書中的公鑰加密密鑰，發送給SSL服務器。
驗證SSL服務器/SSL客戶端的身份之前，SSL服務器/SSL客戶端需要將從CA獲取的證書發送給對端，對端通過PKI判斷該證書的真實性。如果該證書確實屬於SSL服務器/SSL客戶端，則對端利用該證書中的公鑰驗證SSL服務器/SSL客戶端的身份。
圖4 SSL協議分層
如圖4所示，SSL位於應用層和傳輸層之間，它可以為任何基於TCP等可靠連接的應用層協議提供安全性保證。SSL協議本身分為兩層：
l 上層為SSL握手協議（SSL handshake protocol）、SSL密碼變化協議（SSL change cipher spec protocol）和SSL警告協議（SSL alert protocol）；
l 底層為SSL記錄協議（SSL record protocol）。
其中：
l SSL握手協議：是SSL協議非常重要的組成部分，用來協商通信過程中使用的加密套件（加密算法、密鑰交換算法和MAC算法等）、在服務器和客戶端之間安全地交換密鑰、實現服務器和客戶端的身份驗證。
l SSL密碼變化協議：客戶端和服務器端通過密碼變化協議通知對端，隨後的報文都將使用新協商的加密套件和密鑰進行保護和傳輸。
l SSL警告協議：用來向通信對端報告告警信息，消息中包含告警的嚴重級別和描述。
l SSL記錄協議：主要負責對上層的數據（SSL握手協議、SSL密碼變化協議、SSL警告協議和應用層協議報文）進行分塊、計算並添加MAC值、加密，並把處理後的記錄塊傳輸給對端。
SSL通過握手過程在客戶端和服務器之間協商會話參數，並建立會話。會話包含的主要參數有會話ID、對方的證書、加密套件（密鑰交換算法、數據加密算法和MAC算法等）以及主密鑰（master secret）。通過SSL會話傳輸的數據，都將采用該會話的主密鑰和加密套件進行加密、計算MAC等處理。
不同情況下，SSL握手過程存在差異。下麵將分別描述以下三種情況下的握手過程：
l 隻驗證服務器的SSL握手過程
l 驗證服務器和客戶端的SSL握手過程
l 恢複原有會話的SSL握手過程
圖5 隻驗證服務器的SSL握手過程
如圖5所示，隻需要驗證SSL服務器身份，不需要驗證SSL客戶端身份時，SSL的握手過程為：
(1) SSL客戶端通過Client Hello消息將它支持的SSL版本、加密算法、密鑰交換算法、MAC算法等信息發送給SSL服務器。
(2) SSL服務器確定本次通信采用的SSL版本和加密套件，並通過Server Hello消息通知給SSL客戶端。如果SSL服務器允許SSL客戶端在以後的通信中重用本次會話，則SSL服務器會為本次會話分配會話ID，並通過Server Hello消息發送給SSL客戶端。
(3) SSL服務器將攜帶自己公鑰信息的數字證書通過Certificate消息發送給SSL客戶端。
(4) SSL服務器發送Server Hello Done消息，通知SSL客戶端版本和加密套件協商結束，開始進行密鑰交換。
(5) SSL客戶端驗證SSL服務器的證書合法後，利用證書中的公鑰加密SSL客戶端隨機生成的premaster secret，並通過Client Key Exchange消息發送給SSL服務器。
(6) SSL客戶端發送Change Cipher Spec消息，通知SSL服務器後續報文將采用協商好的密鑰和加密套件進行加密和MAC計算。
(7) SSL客戶端計算已交互的握手消息（除Change Cipher Spec消息外所有已交互的消息）的Hash值，利用協商好的密鑰和加密套件處理Hash值（計算並添加MAC值、加密等），並通過Finished消息發送給SSL服務器。SSL服務器利用同樣的方法計算已交互的握手消息的Hash值，並與Finished消息的解密結果比較，如果二者相同，且MAC值驗證成功，則證明密鑰和加密套件協商成功。
(8) 同樣地，SSL服務器發送Change Cipher Spec消息，通知SSL客戶端後續報文將采用協商好的密鑰和加密套件進行加密和MAC計算。
(9) SSL服務器計算已交互的握手消息的Hash值，利用協商好的密鑰和加密套件處理Hash值（計算並添加MAC值、加密等），並通過Finished消息發送給SSL客戶端。SSL客戶端利用同樣的方法計算已交互的握手消息的Hash值，並與Finished消息的解密結果比較，如果二者相同，且MAC值驗證成功，則證明密鑰和加密套件協商成功。
SSL客戶端接收到SSL服務器發送的Finished消息後，如果解密成功，則可以判斷SSL服務器是數字證書的擁有者，即SSL服務器身份驗證成功，因為隻有擁有私鑰的SSL服務器才能從Client Key Exchange消息中解密得到premaster secret，從而間接地實現了SSL客戶端對SSL服務器的身份驗證。
& 說明：
l Change Cipher Spec消息屬於SSL密碼變化協議，其他握手過程交互的消息均屬於SSL握手協議，統稱為SSL握手消息。
l 計算Hash值，指的是利用Hash算法（MD5或SHA）將任意長度的數據轉換為固定長度的數據。
圖6 驗證服務器和客戶端的SSL握手過程
SSL客戶端的身份驗證是可選的，由SSL服務器決定是否驗證SSL客戶端的身份。如圖6中藍色部分標識的內容所示，如果SSL服務器驗證SSL客戶端身份，則SSL服務器和SSL客戶端除了交互“3.2.1 隻驗證服務器的SSL握手過程”中的消息協商密鑰和加密套件外，還需要進行以下操作：
(1) SSL服務器發送Certificate Request消息，請求SSL客戶端將其證書發送給SSL服務器。
(2) SSL客戶端通過Certificate消息將攜帶自己公鑰的證書發送給SSL服務器。SSL服務器驗證該證書的合法性。
(3) SSL客戶端計算已交互的握手消息、主密鑰的Hash值，利用自己的私鑰對其進行加密，並通過Certificate Verify消息發送給SSL服務器。
(4) SSL服務器計算已交互的握手消息、主密鑰的Hash值，利用SSL客戶端證書中的公鑰解密Certificate Verify消息，並將解密結果與計算出的Hash值比較。如果二者相同，則SSL客戶端身份驗證成功。
圖7 恢複原有會話的SSL握手過程
協商會話參數、建立會話的過程中，需要使用非對稱密鑰算法來加密密鑰、驗證通信對端的身份，計算量較大，占用了大量的係統資源。為了簡化SSL握手過程，SSL允許重用已經協商過的會話，具體過程為：
(1) SSL客戶端發送Client Hello消息，消息中的會話ID設置為計劃重用的會話的ID。
(2) SSL服務器如果允許重用該會話，則通過在Server Hello消息中設置相同的會話ID來應答。這樣，SSL客戶端和SSL服務器就可以利用原有會話的密鑰和加密套件，不必重新協商。
(3) SSL客戶端發送Change Cipher Spec消息，通知SSL服務器後續報文將采用原有會話的密鑰和加密套件進行加密和MAC計算。
(4) SSL客戶端計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值，並通過Finished消息發送給SSL服務器，以便SSL服務器判斷密鑰和加密套件是否正確。
(5) 同樣地，SSL服務器發送Change Cipher Spec消息，通知SSL客戶端後續報文將采用原有會話的密鑰和加密套件進行加密和MAC計算。
(6) SSL服務器計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值，並通過Finished消息發送給SSL客戶端，以便SSL客戶端判斷密鑰和加密套件是否正確。
HTTPS是基於SSL安全連接的HTTP協議。HTTPS通過SSL提供的數據加密、身份驗證和消息完整性驗證等安全機製，為Web訪問提供了安全性保證，廣泛應用於網上銀行、電子商務等領域。
圖8為HTTPS在網上銀行中的應用。某銀行為了方便客戶，提供了網上銀行業務，客戶可以通過訪問銀行的Web服務器進行帳戶查詢、轉帳等。通過在客戶和銀行的Web服務器之間建立SSL連接，可以保證客戶的信息不被非法竊取。
圖8 HTTPS在網上銀行中的應用
SSL VPN是以SSL為基礎的VPN技術，利用SSL提供的安全機製，為用戶遠程訪問公司內部網絡提供了安全保證。如圖9所示，SSL VPN通過在遠程接入用戶和SSL VPN網關之間建立SSL安全連接，允許用戶通過各種Web瀏覽器，各種網絡接入方式，在任何地方遠程訪問企業網絡資源，並能夠保證企業網絡的安全，保護企業內部信息不被竊取。
圖9 SSL VPN的典型組網環境
l draft-freier-ssl-version3-02：The SSL Protocol Version 3.0
Copyright ©2008 杭州華三通信技術有限公司 版權所有，保留一切權利。
非經本公司書麵許可，任何單位和個人不得擅自摘抄、複製本文檔內容的部分或全部，並不得以任何形式傳播。
本文檔中的信息可能變動，恕不另行通知。
售前谘詢
售後谘詢
人工在線谘詢
