SSL技術(shù)白皮書SSL技術(shù)白皮書 關(guān)鍵詞：SSL，PKI，MAC 摘 要：SSL利用數(shù)據(jù)加密、身份驗證和消息完整性驗證機制，為基于TCP等可靠連接的應用層協(xié)議提供安全性保證。本文介紹了SSL的產(chǎn)生背景、安全機制、工作過程及典型組網(wǎng)應用。 縮略語：
1 概述1.1 產(chǎn)生背景基于萬維網(wǎng)的電子商務和網(wǎng)上銀行等新興應用，極大地方便了人們的日常生活，受到人們的青睞。由于這些應用都需要在網(wǎng)絡上進行在線交易，它們對網(wǎng)絡通信的安全性提出了更高的要求。傳統(tǒng)的萬維網(wǎng)協(xié)議HTTP不具備安全機制——采用明文的形式傳輸數(shù)據(jù)、不能驗證通信雙方的身份、無法防止傳輸?shù)臄?shù)據(jù)被篡改等，導致HTTP無法滿足電子商務和網(wǎng)上銀行等應用的安全性要求。 Netscape公司提出的安全協(xié)議SSL，利用數(shù)據(jù)加密、身份驗證和消息完整性驗證機制，為網(wǎng)絡上數(shù)據(jù)的傳輸提供安全性保證。SSL可以為HTTP提供安全連接，從而很大程度上改善了萬維網(wǎng)的安全性問題。 1.2 技術(shù)優(yōu)點SSL具有如下優(yōu)點： l 提供較高的安全性保證。SSL利用數(shù)據(jù)加密、身份驗證和消息完整性驗證機制，保證網(wǎng)絡上數(shù)據(jù)傳輸?shù)陌踩浴?/span> l 支持各種應用層協(xié)議。雖然SSL設計的初衷是為了解決萬維網(wǎng)安全性問題，但是由于SSL位于應用層和傳輸層之間，它可以為任何基于TCP等可靠連接的應用層協(xié)議提供安全性保證。 l 部署簡單。目前SSL已經(jīng)成為網(wǎng)絡中用來鑒別網(wǎng)站和網(wǎng)頁瀏覽者身份，在瀏覽器使用者及Web服務器之間進行加密通信的全球化標準。SSL協(xié)議已被集成到大部分的瀏覽器中，如IE、Netscape、Firefox等。這就意味著幾乎任意一臺裝有瀏覽器的計算機都支持SSL連接，不需要安裝額外的客戶端軟件。 2 協(xié)議安全機制SSL協(xié)議實現(xiàn)的安全機制包括： l 數(shù)據(jù)傳輸?shù)臋C密性：利用對稱密鑰算法對傳輸?shù)臄?shù)據(jù)進行加密。 l 身份驗證機制：基于證書利用數(shù)字簽名方法對服務器和客戶端進行身份驗證，其中客戶端的身份驗證是可選的。 l 消息完整性驗證：消息傳輸過程中使用MAC算法來檢驗消息的完整性。 2.1 數(shù)據(jù)傳輸?shù)臋C密性網(wǎng)絡上傳輸?shù)臄?shù)據(jù)很容易被非法用戶竊取，SSL采用在通信雙方之間建立加密通道的方法保證數(shù)據(jù)傳輸?shù)臋C密性。 所謂加密通道，是指發(fā)送方在發(fā)送數(shù)據(jù)前，使用加密算法和加密密鑰對數(shù)據(jù)進行加密，然后將數(shù)據(jù)發(fā)送給對方；接收方接收到數(shù)據(jù)后，利用解密算法和解密密鑰從密文中獲取明文。沒有解密密鑰的第三方，無法將密文恢復為明文，從而保證數(shù)據(jù)傳輸?shù)臋C密性。 加解密算法分為兩類： l 對稱密鑰算法：數(shù)據(jù)加密和解密時使用相同的密鑰。 l 非對稱密鑰算法：數(shù)據(jù)加密和解密時使用不同的密鑰，一個是公開的公鑰，一個是由用戶秘密保存的私鑰。利用公鑰（或私鑰）加密的數(shù)據(jù)只能用相應的私鑰（或公鑰）才能解密。 與非對稱密鑰算法相比，對稱密鑰算法具有計算速度快的優(yōu)點，通常用于對大量信息進行加密（如對所有報文加密）；而非對稱密鑰算法，一般用于數(shù)字簽名和對較少的信息進行加密。 SSL加密通道上的數(shù)據(jù)加解密使用對稱密鑰算法，目前主要支持的算法有DES、3DES、AES等，這些算法都可以有效地防止交互數(shù)據(jù)被竊聽。 對稱密鑰算法要求解密密鑰和加密密鑰完全一致。因此，利用對稱密鑰算法加密傳輸數(shù)據(jù)之前，需要在通信兩端部署相同的密鑰。對稱密鑰的部署方法請參見“2.4 利用非對稱密鑰算法保證密鑰本身的安全”。 2.2 身份驗證機制電子商務和網(wǎng)上銀行等應用中必須保證要登錄的Web服務器是真實的，以免重要信息被非法竊取。SSL利用數(shù)字簽名來驗證通信對端的身份。 非對稱密鑰算法可以用來實現(xiàn)數(shù)字簽名。由于通過私鑰加密后的數(shù)據(jù)只能利用對應的公鑰進行解密，因此根據(jù)解密是否成功，就可以判斷發(fā)送者的身份，如同發(fā)送者對數(shù)據(jù)進行了“簽名”。例如，Alice使用自己的私鑰對一段固定的信息加密后發(fā)給Bob，Bob利用Alice的公鑰解密，如果解密結(jié)果與固定信息相同，那么就能夠確認信息的發(fā)送者為Alice，這個過程就稱為數(shù)字簽名。 SSL客戶端必須驗證SSL服務器的身份，SSL服務器是否驗證SSL客戶端的身份，則由SSL服務器決定。SSL客戶端和SSL服務器的身份驗證過程，請參見“3.2 SSL握手過程”。 使用數(shù)字簽名驗證身份時，需要確保被驗證者的公鑰是真實的，否則，非法用戶可能會冒充被驗證者與驗證者通信。如圖1所示，Cindy冒充Bob，將自己的公鑰發(fā)給Alice，并利用自己的私鑰計算出簽名發(fā)送給Alice，Alice利用“Bob”的公鑰（實際上為Cindy的公鑰）成功驗證該簽名，則Alice認為Bob的身份驗證成功，而實際上與Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的機制保證公鑰的真實性，詳細介紹請參見“2.5 利用PKI保證公鑰的真實性”。
圖1 偽造公鑰 2.3 消息完整性驗證為了避免網(wǎng)絡中傳輸?shù)臄?shù)據(jù)被非法篡改，SSL利用基于MD5或SHA的MAC算法來保證消息的完整性。 MAC算法是在密鑰參與下的數(shù)據(jù)摘要算法，能將密鑰和任意長度的數(shù)據(jù)轉(zhuǎn)換為固定長度的數(shù)據(jù)。利用MAC算法驗證消息完整性的過程如圖2所示。發(fā)送者在密鑰的參與下，利用MAC算法計算出消息的MAC值，并將其加在消息之后發(fā)送給接收者。接收者利用同樣的密鑰和MAC算法計算出消息的MAC值，并與接收到的MAC值比較。如果二者相同，則報文沒有改變；否則，報文在傳輸過程中被修改，接收者將丟棄該報文。
圖2 MAC算法示意圖 MAC算法具有如下特征，使其能夠用來驗證消息的完整性： l 消息的任何改變，都會引起輸出的固定長度數(shù)據(jù)產(chǎn)生變化。通過比較MAC值，可以保證接收者能夠發(fā)現(xiàn)消息的改變。 l MAC算法需要密鑰的參與，因此沒有密鑰的非法用戶在改變消息的內(nèi)容后，無法添加正確的MAC值，從而保證非法用戶無法隨意修改消息內(nèi)容。 MAC算法要求通信雙方具有相同的密鑰，否則MAC值驗證將會失敗。因此，利用MAC算法驗證消息完整性之前，需要在通信兩端部署相同的密鑰。MAC密鑰的部署方法請參見“2.4 利用非對稱密鑰算法保證密鑰本身的安全”。 2.4 利用非對稱密鑰算法保證密鑰本身的安全對稱密鑰算法和MAC算法要求通信雙方具有相同的密鑰，否則解密或MAC值驗證將失敗。因此，要建立加密通道或驗證消息完整性，必須先在通信雙方部署一致的密鑰。 SSL利用非對稱密鑰算法加密密鑰的方法實現(xiàn)密鑰交換，保證第三方無法獲取該密鑰。如圖3所示，SSL客戶端（如Web瀏覽器）利用SSL服務器（如Web服務器）的公鑰加密密鑰，將加密后的密鑰發(fā)送給SSL服務器，只有擁有對應私鑰的SSL服務器才能從密文中獲取原始的密鑰。SSL通常采用RSA算法加密傳輸密鑰。
l 實際上，SSL客戶端發(fā)送給SSL服務器的密鑰不能直接用來加密數(shù)據(jù)或計算MAC值，該密鑰是用來計算對稱密鑰和MAC密鑰的信息，稱為premaster secret。SSL客戶端和SSL服務器利用premaster secret計算出相同的主密鑰（master secret），再利用master secret生成用于對稱密鑰算法、MAC算法等的密鑰。premaster secret是計算對稱密鑰、MAC算法密鑰的關(guān)鍵。 l 用來實現(xiàn)密鑰交換的算法稱為密鑰交換算法。非對稱密鑰算法RSA用于密鑰交換時，也可以稱之為密鑰交換算法。
利用非對稱密鑰算法加密密鑰之前，發(fā)送者需要獲取接收者的公鑰，并保證該公鑰確實屬于接收者，否則，密鑰可能會被非法用戶竊取。如圖1所示，Cindy冒充Bob，將自己的公鑰發(fā)給Alice，Alice利用Cindy的公鑰加密發(fā)送給Bob的數(shù)據(jù)，Bob由于沒有對應的私鑰無法解密該數(shù)據(jù)，而Cindy截取數(shù)據(jù)后，可以利用自己的私鑰解密該數(shù)據(jù)。SSL利用PKI提供的機制保證公鑰的真實性，詳細介紹請參見“2.5 利用PKI保證公鑰的真實性”。 2.5 利用PKI保證公鑰的真實性PKI通過數(shù)字證書來發(fā)布用戶的公鑰，并提供了驗證公鑰真實性的機制。數(shù)字證書（簡稱證書）是一個包含用戶的公鑰及其身份信息的文件，證明了用戶與公鑰的關(guān)聯(lián)。數(shù)字證書由權(quán)威機構(gòu)——CA簽發(fā)，并由CA保證數(shù)字證書的真實性。 SSL客戶端把密鑰加密傳遞給SSL服務器之前，SSL服務器需要將從CA獲取的證書發(fā)送給SSL客戶端，SSL客戶端通過PKI判斷該證書的真實性。如果該證書確實屬于SSL服務器，則利用該證書中的公鑰加密密鑰，發(fā)送給SSL服務器。 驗證SSL服務器/SSL客戶端的身份之前，SSL服務器/SSL客戶端需要將從CA獲取的證書發(fā)送給對端，對端通過PKI判斷該證書的真實性。如果該證書確實屬于SSL服務器/SSL客戶端，則對端利用該證書中的公鑰驗證SSL服務器/SSL客戶端的身份。 3 協(xié)議工作過程3.1 SSL的分層結(jié)構(gòu)
圖4 SSL協(xié)議分層 如圖4所示，SSL位于應用層和傳輸層之間，它可以為任何基于TCP等可靠連接的應用層協(xié)議提供安全性保證。SSL協(xié)議本身分為兩層： l 上層為SSL握手協(xié)議（SSL handshake protocol）、SSL密碼變化協(xié)議（SSL change cipher spec protocol）和SSL警告協(xié)議（SSL alert protocol）； l 底層為SSL記錄協(xié)議（SSL record protocol）。 其中： l SSL握手協(xié)議：是SSL協(xié)議非常重要的組成部分，用來協(xié)商通信過程中使用的加密套件（加密算法、密鑰交換算法和MAC算法等）、在服務器和客戶端之間安全地交換密鑰、實現(xiàn)服務器和客戶端的身份驗證。 l SSL密碼變化協(xié)議：客戶端和服務器端通過密碼變化協(xié)議通知對端，隨后的報文都將使用新協(xié)商的加密套件和密鑰進行保護和傳輸。 l SSL警告協(xié)議：用來向通信對端報告告警信息，消息中包含告警的嚴重級別和描述。 l SSL記錄協(xié)議：主要負責對上層的數(shù)據(jù)（SSL握手協(xié)議、SSL密碼變化協(xié)議、SSL警告協(xié)議和應用層協(xié)議報文）進行分塊、計算并添加MAC值、加密，并把處理后的記錄塊傳輸給對端。 3.2 SSL握手過程SSL通過握手過程在客戶端和服務器之間協(xié)商會話參數(shù)，并建立會話。會話包含的主要參數(shù)有會話ID、對方的證書、加密套件（密鑰交換算法、數(shù)據(jù)加密算法和MAC算法等）以及主密鑰（master secret）。通過SSL會話傳輸?shù)臄?shù)據(jù)，都將采用該會話的主密鑰和加密套件進行加密、計算MAC等處理。 不同情況下，SSL握手過程存在差異。下面將分別描述以下三種情況下的握手過程： l 只驗證服務器的SSL握手過程 l 驗證服務器和客戶端的SSL握手過程 l 恢復原有會話的SSL握手過程 3.2.1 只驗證服務器的SSL握手過程
圖5 只驗證服務器的SSL握手過程 如圖5所示，只需要驗證SSL服務器身份，不需要驗證SSL客戶端身份時，SSL的握手過程為： (1) SSL客戶端通過Client Hello消息將它支持的SSL版本、加密算法、密鑰交換算法、MAC算法等信息發(fā)送給SSL服務器。 (2) SSL服務器確定本次通信采用的SSL版本和加密套件，并通過Server Hello消息通知給SSL客戶端。如果SSL服務器允許SSL客戶端在以后的通信中重用本次會話，則SSL服務器會為本次會話分配會話ID，并通過Server Hello消息發(fā)送給SSL客戶端。 (3) SSL服務器將攜帶自己公鑰信息的數(shù)字證書通過Certificate消息發(fā)送給SSL客戶端。 (4) SSL服務器發(fā)送Server Hello Done消息，通知SSL客戶端版本和加密套件協(xié)商結(jié)束，開始進行密鑰交換。 (5) SSL客戶端驗證SSL服務器的證書合法后，利用證書中的公鑰加密SSL客戶端隨機生成的premaster secret，并通過Client Key Exchange消息發(fā)送給SSL服務器。 (6) SSL客戶端發(fā)送Change Cipher Spec消息，通知SSL服務器后續(xù)報文將采用協(xié)商好的密鑰和加密套件進行加密和MAC計算。 (7) SSL客戶端計算已交互的握手消息（除Change Cipher Spec消息外所有已交互的消息）的Hash值，利用協(xié)商好的密鑰和加密套件處理Hash值（計算并添加MAC值、加密等），并通過Finished消息發(fā)送給SSL服務器。SSL服務器利用同樣的方法計算已交互的握手消息的Hash值，并與Finished消息的解密結(jié)果比較，如果二者相同，且MAC值驗證成功，則證明密鑰和加密套件協(xié)商成功。 (8) 同樣地，SSL服務器發(fā)送Change Cipher Spec消息，通知SSL客戶端后續(xù)報文將采用協(xié)商好的密鑰和加密套件進行加密和MAC計算。 (9) SSL服務器計算已交互的握手消息的Hash值，利用協(xié)商好的密鑰和加密套件處理Hash值（計算并添加MAC值、加密等），并通過Finished消息發(fā)送給SSL客戶端。SSL客戶端利用同樣的方法計算已交互的握手消息的Hash值，并與Finished消息的解密結(jié)果比較，如果二者相同，且MAC值驗證成功，則證明密鑰和加密套件協(xié)商成功。 SSL客戶端接收到SSL服務器發(fā)送的Finished消息后，如果解密成功，則可以判斷SSL服務器是數(shù)字證書的擁有者，即SSL服務器身份驗證成功，因為只有擁有私鑰的SSL服務器才能從Client Key Exchange消息中解密得到premaster secret，從而間接地實現(xiàn)了SSL客戶端對SSL服務器的身份驗證。 & 說明： l Change Cipher Spec消息屬于SSL密碼變化協(xié)議，其他握手過程交互的消息均屬于SSL握手協(xié)議，統(tǒng)稱為SSL握手消息。 l 計算Hash值，指的是利用Hash算法（MD5或SHA）將任意長度的數(shù)據(jù)轉(zhuǎn)換為固定長度的數(shù)據(jù)。
3.2.2 驗證服務器和客戶端的SSL握手過程
圖6 驗證服務器和客戶端的SSL握手過程 SSL客戶端的身份驗證是可選的，由SSL服務器決定是否驗證SSL客戶端的身份。如圖6中藍色部分標識的內(nèi)容所示，如果SSL服務器驗證SSL客戶端身份，則SSL服務器和SSL客戶端除了交互“3.2.1 只驗證服務器的SSL握手過程”中的消息協(xié)商密鑰和加密套件外，還需要進行以下操作： (1) SSL服務器發(fā)送Certificate Request消息，請求SSL客戶端將其證書發(fā)送給SSL服務器。 (2) SSL客戶端通過Certificate消息將攜帶自己公鑰的證書發(fā)送給SSL服務器。SSL服務器驗證該證書的合法性。 (3) SSL客戶端計算已交互的握手消息、主密鑰的Hash值，利用自己的私鑰對其進行加密，并通過Certificate Verify消息發(fā)送給SSL服務器。 (4) SSL服務器計算已交互的握手消息、主密鑰的Hash值，利用SSL客戶端證書中的公鑰解密Certificate Verify消息，并將解密結(jié)果與計算出的Hash值比較。如果二者相同，則SSL客戶端身份驗證成功。 3.2.3 恢復原有會話的SSL握手過程
圖7 恢復原有會話的SSL握手過程 協(xié)商會話參數(shù)、建立會話的過程中，需要使用非對稱密鑰算法來加密密鑰、驗證通信對端的身份，計算量較大，占用了大量的系統(tǒng)資源。為了簡化SSL握手過程，SSL允許重用已經(jīng)協(xié)商過的會話，具體過程為： (1) SSL客戶端發(fā)送Client Hello消息，消息中的會話ID設置為計劃重用的會話的ID。 (2) SSL服務器如果允許重用該會話，則通過在Server Hello消息中設置相同的會話ID來應答。這樣，SSL客戶端和SSL服務器就可以利用原有會話的密鑰和加密套件，不必重新協(xié)商。 (3) SSL客戶端發(fā)送Change Cipher Spec消息，通知SSL服務器后續(xù)報文將采用原有會話的密鑰和加密套件進行加密和MAC計算。 (4) SSL客戶端計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值，并通過Finished消息發(fā)送給SSL服務器，以便SSL服務器判斷密鑰和加密套件是否正確。 (5) 同樣地，SSL服務器發(fā)送Change Cipher Spec消息，通知SSL客戶端后續(xù)報文將采用原有會話的密鑰和加密套件進行加密和MAC計算。 (6) SSL服務器計算已交互的握手消息的Hash值，利用原有會話的密鑰和加密套件處理Hash值，并通過Finished消息發(fā)送給SSL客戶端，以便SSL客戶端判斷密鑰和加密套件是否正確。 4 典型組網(wǎng)應用4.1 HTTPSHTTPS是基于SSL安全連接的HTTP協(xié)議。HTTPS通過SSL提供的數(shù)據(jù)加密、身份驗證和消息完整性驗證等安全機制，為Web訪問提供了安全性保證，廣泛應用于網(wǎng)上銀行、電子商務等領(lǐng)域。 圖8為HTTPS在網(wǎng)上銀行中的應用。某銀行為了方便客戶，提供了網(wǎng)上銀行業(yè)務，客戶可以通過訪問銀行的Web服務器進行帳戶查詢、轉(zhuǎn)帳等。通過在客戶和銀行的Web服務器之間建立SSL連接，可以保證客戶的信息不被非法竊取。
圖8 HTTPS在網(wǎng)上銀行中的應用 4.2 SSL VPNSSL VPN是以SSL為基礎的VPN技術(shù)，利用SSL提供的安全機制，為用戶遠程訪問公司內(nèi)部網(wǎng)絡提供了安全保證。如圖9所示，SSL VPN通過在遠程接入用戶和SSL VPN網(wǎng)關(guān)之間建立SSL安全連接，允許用戶通過各種Web瀏覽器，各種網(wǎng)絡接入方式，在任何地方遠程訪問企業(yè)網(wǎng)絡資源，并能夠保證企業(yè)網(wǎng)絡的安全，保護企業(yè)內(nèi)部信息不被竊取。
圖9 SSL VPN的典型組網(wǎng)環(huán)境 |
|
|
