關鍵詞：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 |
虛擬專有網絡 |
1 概述
1.1 產生背景
基於萬維網的電子商務和網上銀行等新興應用，極大地方便了人們的日常生活。受到人們的青睞。
因為這些應用都須要在網絡上進行在線交易，它們對網絡通信的安全性提出了更高的要求。傳統的萬維網協議HTTP不具備安全機制——採用明文的形式數據傳輸、不能驗證通信兩方的身份、無法防止傳輸的數據被篡改等，導致HTTP無法滿足電子商務和網上銀行等應用的安全性要求。
Netscape公司提出的安全協議SSL，利用數據加密、身份驗證和消息完整性驗證機制，為網絡上數據的傳輸提供安全性保證。SSL能夠為HTTP提供安全連接，從而非常大程度上改善了萬維網的安全性問題。
1.2 技術長處
SSL具有例如以下長處：
l 提供較高的安全性保證。
SSL利用數據加密、身份驗證和消息完整性驗證機制。保證網絡上傳輸數據的安全性。
l 支持各種應用層協議。
盡管SSL設計的初衷是為了解決萬維網安全性問題，可是因為SSL位於應用層和傳輸層之間。它能夠為不論什么基於TCP等可靠連接的應用層協議提供安全性保證。
l 部署簡單。眼下SSL已經成為網絡中用來鑒別站點和網頁瀏覽者身份，在瀏覽器使用者及Webserver之間進行加密通信的全球化標准。SSL協議已被集成到大部分的瀏覽器中，如IE、Netscape、Firefox等。這就意味着差點兒隨意一台裝有瀏覽器的計算機都支持SSL連接。不須要安裝額外的client軟件。
2 協議安全機制
SSL協議實現的安全機制包含：
l 傳輸數據的機密性：利用對稱密鑰算法對傳輸的數據進行加密。
l 身份驗證機制：基於證書利用數字簽名方法對server和client進行身份驗證，當中client的身份驗證是可選的。
l 消息完整性驗證：消息傳輸過程中使用MAC算法來檢驗消息的完整性。
2.1 傳輸數據的機密性
網絡上傳輸的數據非常easy被非法用戶竊取，SSL採用在通信兩方之間建立加密通道的方法保證傳輸數據的機密性。
所謂加密通道，是指發送方在發送數據前，使用加密算法和加密密鑰對數據進行加密，然后將數據發送給對方。接收方接收到數據后，利用解密算法和解密密鑰從密文中獲取明文。沒有解密密鑰的第三方，無法將密文恢復為明文，從而保證傳輸數據的機密性。
加解密算法分為兩類：
l 對稱密鑰算法：數據加密和解密時使用同樣的密鑰。
l 非對稱密鑰算法：數據加密和解密時使用不同的密鑰，一個是公開的公鑰，一個是由用戶秘密保存的私鑰。
利用公鑰（或私鑰）加密的數據僅僅能用對應的私鑰（或公鑰）才干解密。
與非對稱密鑰算法相比。對稱密鑰算法具有計算速度快的長處，通經常使用於對大量信息進行加密（如對全部報文加密）；而非對稱密鑰算法，一般用於數字簽名和對較少的信息進行加密。
SSL加密通道上的數據加解密使用對稱密鑰算法。眼下主要支持的算法有DES、3DES、AES等，這些算法都能夠有效地防止交互數據被竊聽。
對稱密鑰算法要求解密密鑰和加密密鑰全然一致。因此，利用對稱密鑰算法加密數據傳輸之前。須要在通信兩端部署同樣的密鑰。對稱密鑰的部署方法請參見“2.4 利用非對稱密鑰算法保證密鑰本身的安全”。
2.2 身份驗證機制
電子商務和網上銀行等應用中必須保證要登錄的Webserver是真實的，以免重要信息被非法竊取。SSL利用數字簽名來驗證通信對端的身份。
非對稱密鑰算法能夠用來實現數字簽名。因為通過私鑰加密后的數據僅僅能利用相應的公鑰進行解密，因此依據解密是否成功，就能夠推斷發送者的身份。如同發送者對數據進行了“簽名”。比如。Alice使用自己的私鑰對一段固定的信息加密后發給Bob，Bob利用Alice的公鑰解密，假設解密結果與固定信息同樣。那么就能夠確認信息的發送者為Alice，這個過程就稱為數字簽名。
SSLclient必須驗證SSLserver的身份，SSLserver是否驗證SSLclient的身份。則由SSLserver決定。SSLclient和SSLserver的身份驗證過程。請參見“3.2 SSL握手過程”。
使用數字簽名驗證身份時。須要確保被驗證者的公鑰是真實的，否則。非法用戶可能會冒充被驗證者與驗證者通信。如圖1所看到的。Cindy冒充Bob，將自己的公鑰發給Alice，並利用自己的私鑰計算出簽名發送給Alice，Alice利用“Bob”的公鑰（實際上為Cindy的公鑰）成功驗證該簽名，則Alice覺得Bob的身份驗證成功，而實際上與Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的機制保證公鑰的真實性，具體介紹請參見“2.5 利用PKI保證公鑰的真實性”。
圖1 偽造公鑰
2.3 消息完整性驗證
為了避免網絡中傳輸的數據被非法篡改，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 利用非對稱密鑰算法保證密鑰本身的安全”。
2.4 利用非對稱密鑰算法保證密鑰本身的安全
對稱密鑰算法和MAC算法要求通信兩方具有同樣的密鑰。否則解密或MAC值驗證將失敗。因此。要建立加密通道或驗證消息完整性，必須先在通信兩方部署一致的密鑰。
SSL利用非對稱密鑰算法加密密鑰的方法實現密鑰交換，保證第三方無法獲取該密鑰。如圖3所看到的，SSLclient（如Web瀏覽器）利用SSLserver（如Webserver）的公鑰加密密鑰，將加密后的密鑰發送給SSLserver。僅僅有擁有相應私鑰的SSLserver才干從密文中獲取原始的密鑰。SSL通常採用RSA算法加密傳輸密鑰。
l 實際上，SSLclient發送給SSLserver的密鑰不能直接用來加密數據或計算MAC值。該密鑰是用來計算對稱密鑰和MAC密鑰的信息，稱為premaster secret。SSLclient和SSLserver利用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保證公鑰的真實性”。
2.5 利用PKI保證公鑰的真實性
PKI通過數字證書來公布用戶的公鑰，並提供了驗證公鑰真實性的機制。數字證書（簡稱證書）是一個包括用戶的公鑰及其身份信息的文件，證明了用戶與公鑰的關聯。
數字證書由權威機構——CA簽發，並由CA保證數字證書的真實性。
SSLclient把密鑰加密傳遞給SSLserver之前，SSLserver須要將從CA獲取的證書發送給SSLclient，SSLclient通過PKI推斷該證書的真實性。假設該證書確實屬於SSLserver，則利用該證書中的公鑰加密密鑰，發送給SSLserver。
驗證SSLserver/SSLclient的身份之前，SSLserver/SSLclient須要將從CA獲取的證書發送給對端。對端通過PKI推斷該證書的真實性。
假設該證書確實屬於SSLserver/SSLclient，則對端利用該證書中的公鑰驗證SSLserver/SSLclient的身份。
3 協議工作過程
3.1 SSL的分層結構
圖4 SSL協議分層
如圖4所看到的，SSL位於應用層和傳輸層之間，它能夠為不論什么基於TCP等可靠連接的應用層協議提供安全性保證。SSL協議本身分為兩層：
l 上層為SSL握手協議（SSL handshake protocol）、SSLpassword變化協議（SSL change cipher spec protocol）和SSL警告協議（SSL alert protocol）。
l 底層為SSL記錄協議（SSL record protocol）。
當中：
l SSL握手協議：是SSL協議很重要的組成部分。用來協商通信過程中使用的加密套件（加密算法、密鑰交換算法和MAC算法等）、在server和client之間安全地交換密鑰、實現server和client的身份驗證。
l SSLpassword變化協議：client和server端通過password變化協議通知對端。隨后的報文都將使用新協商的加密套件和密鑰進行保護和傳輸。
l SSL警告協議：用來向通信對端報告告警信息，消息中包括告警的嚴重級別和描寫敘述。
l SSL記錄協議：主要負責對上層的數據（SSL握手協議、SSLpassword變化協議、SSL警告協議和應用層協議報文）進行分塊、計算並加入MAC值、加密。並把處理后的記錄塊傳輸給對端。
3.2 SSL握手過程
SSL通過握手過程在client和server之間協商會話參數，並建立會話。會話包括的主要參數有會話ID、對方的證書、加密套件（密鑰交換算法、數據加密算法和MAC算法等）以及主密鑰（master secret）。通過SSL會話傳輸的數據，都將採用該會話的主密鑰和加密套件進行加密、計算MAC等處理。
不同情況下，SSL握手過程存在差異。
以下將分別描寫敘述以下三種情況下的握手過程：
l 僅僅驗證server的SSL握手過程
l 驗證server和client的SSL握手過程
l 恢復原有會話的SSL握手過程
3.2.1 僅僅驗證server的SSL握手過程
如圖5所看到的，僅僅須要驗證SSLserver身份，不須要驗證SSLclient身份時，SSL的握手過程為：
(1) SSLclient通過Client Hello消息將它支持的SSL版本號、加密算法、密鑰交換算法、MAC算法等信息發送給SSLserver。
(2) SSLserver確定本次通信採用的SSL版本號和加密套件，並通過Server Hello消息通知給SSLclient。假設SSLserver同意SSLclient在以后的通信中重用本次會話，則SSLserver會為本次會話分配會話ID。並通過Server Hello消息發送給SSLclient。
(3) SSLserver將攜帶自己公鑰信息的數字證書通過Certificate消息發送給SSLclient。
(4) SSLserver發送Server Hello Done消息。通知SSLclient版本號和加密套件協商結束。開始進行密鑰交換。
(5) SSLclient驗證SSLserver的證書合法后，利用證書中的公鑰加密SSLclient隨機生成的premaster secret，並通過Client Key Exchange消息發送給SSLserver。
(6) SSLclient發送Change Cipher Spec消息，通知SSLserver興許報文將採用協商好的密鑰和加密套件進行加密和MAC計算。
(7) SSLclient計算已交互的握手消息（除Change Cipher Spec消息外全部已交互的消息）的Hash值，利用協商好的密鑰和加密套件處理Hash值（計算並加入MAC值、加密等），並通過Finished消息發送給SSLserver。SSLserver利用相同的方法計算已交互的握手消息的Hash值，並與Finished消息的解密結果比較，假設二者相同，且MAC值驗證成功，則證明密鑰和加密套件協商成功。
(8) 相同地。SSLserver發送Change Cipher Spec消息，通知SSLclient興許報文將採用協商好的密鑰和加密套件進行加密和MAC計算。
(9) SSLserver計算已交互的握手消息的Hash值，利用協商好的密鑰和加密套件處理Hash值（計算並加入MAC值、加密等），並通過Finished消息發送給SSLclient。SSLclient利用相同的方法計算已交互的握手消息的Hash值，並與Finished消息的解密結果比較，假設二者相同。且MAC值驗證成功。則證明密鑰和加密套件協商成功。
SSLclient接收到SSLserver發送的Finished消息后。假設解密成功，則能夠推斷SSLserver是數字證書的擁有者，即SSLserver身份驗證成功，由於僅僅有擁有私鑰的SSLserver才干從Client Key Exchange消息中解密得到premaster secret，從而間接地實現了SSLclient對SSLserver的身份驗證。
& 說明：
l Change Cipher Spec消息屬於SSLpassword變化協議，其它握手過程交互的消息均屬於SSL握手協議，統稱為SSL握手消息。
l 計算Hash值。指的是利用Hash算法（MD5或SHA）將隨意長度的數據轉換為固定長度的數據。
3.2.2 驗證server和client的SSL握手過程
SSLclient的身份驗證是可選的，由SSLserver決定是否驗證SSLclient的身份。
如圖6中藍色部分標識的內容所看到的，假設SSLserver驗證SSLclient身份。則SSLserver和SSLclient除了交互“3.2.1 僅僅驗證server的SSL握手過程”中的消息協商密鑰和加密套件外，還須要進行下面操作：
(1) SSLserver發送Certificate Request消息。請求SSLclient將其證書發送給SSLserver。
(2) SSLclient通過Certificate消息將攜帶自己公鑰的證書發送給SSLserver。SSLserver驗證該證書的合法性。
(3) SSLclient計算已交互的握手消息、主密鑰的Hash值。利用自己的私鑰對其進行加密，並通過Certificate Verify消息發送給SSLserver。
(4) SSLserver計算已交互的握手消息、主密鑰的Hash值。利用SSLclient證書中的公鑰解密Certificate Verify消息，並將解密結果與計算出的Hash值比較。假設二者同樣，則SSLclient身份驗證成功。
3.2.3 恢復原有會話的SSL握手過程
圖7 恢復原有會話的SSL握手過程
協商會話參數、建立會話的過程中。須要使用非對稱密鑰算法來加密密鑰、驗證通信對端的身份。計算量較大，占用了大量的系統資源。
為了簡化SSL握手過程。SSL同意重用已經協商過的會話，詳細過程為：
(1) SSLclient發送Client Hello消息，消息中的會話ID設置為計划重用的會話的ID。
(2) SSLserver假設同意重用該會話，則通過在Server Hello消息中設置同樣的會話ID來應答。這樣，SSLclient和SSLserver就能夠利用原有會話的密鑰和加密套件。不必又一次協商。
(3) SSLclient發送Change Cipher Spec消息，通知SSLserver興許報文將採用原有會話的密鑰和加密套件進行加密和MAC計算。
(4) SSLclient計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值，並通過Finished消息發送給SSLserver，以便SSLserver推斷密鑰和加密套件是否正確。
(5) 相同地。SSLserver發送Change Cipher Spec消息，通知SSLclient興許報文將採用原有會話的密鑰和加密套件進行加密和MAC計算。
(6) SSLserver計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值，並通過Finished消息發送給SSLclient。以便SSLclient推斷密鑰和加密套件是否正確。
4 典型組網應用
4.1 HTTPS
HTTPS是基於SSL安全連接的HTTP協議。HTTPS通過SSL提供的數據加密、身份驗證和消息完整性驗證等安全機制。為Web訪問提供了安全性保證，廣泛應用於網上銀行、電子商務等領域。
圖8為HTTPS在網上銀行中的應用。某銀行為了方便客戶，提供了網上銀行業務，客戶能夠通過訪問銀行的Webserver進行帳戶查詢、轉帳等。
通過在客戶和銀行的Webserver之間建立SSL連接，能夠保證客戶的信息不被非法竊取。
圖8 HTTPS在網上銀行中的應用
4.2 SSL VPN
SSL VPN是以SSL為基礎的VPN技術。利用SSL提供的安全機制，為用戶遠程訪問公司內部網絡提供了安全保證。如圖9所看到的。SSL VPN通過在遠程接入用戶和SSL VPN網關之間建立SSL安全連接，同意用戶通過各種Web瀏覽器，各種網絡接入方式，在不論什么地方遠程訪問企業網絡資源。並可以保證企業網絡的安全，保護企業內部信息不被竊取。
圖紙9 SSL VPN典型組網