SSL(Secure Sockets Layer ，安全套接層)，是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。由Netscape研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸?shù)陌踩?，利用?shù)據(jù)加密(Encryption)技術(shù)，確保數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸過程中不會被截取及竊聽。

當(dāng)前幾乎所有瀏覽器都支持SSL，但是支持的版本有所不同。從圖8-1中可以看到，IE同時支持SSL 2.0和SSL 3.0兩個版本。

圖8-1            IE支持的SSL版本

事實上各位讀者已經(jīng)明白了SSL的工作原理，回顧我前面博客講到的公鑰加密的通信原理，而SSL使用的就是公鑰加密系統(tǒng)?，F(xiàn)在完全可以構(gòu)想基于SSL的數(shù)據(jù)通信流程。前面說過，SSL是一種協(xié)議，本節(jié)重點在于協(xié)議本身和它是如何工作在各種協(xié)議之間來提供安全通信的。

SSL協(xié)議位于TCP/IP協(xié)議模型的網(wǎng)絡(luò)層和應(yīng)用層之間,使用TCP來提供一種可靠的端到端的安全服務(wù),它使客戶/服務(wù)器應(yīng)用之間的通信不被攻擊竊聽,并且始終對服務(wù)器進行認證,還可以選擇對客戶進行認證。SSL協(xié)議在應(yīng)用層通信之前就已經(jīng)完成加密算法、通信密鑰的協(xié)商，以及服務(wù)器認證工作,在此之后,應(yīng)用層協(xié)議所傳送的數(shù)據(jù)都被加密。

SSL協(xié)議體系結(jié)構(gòu)如圖8-2所示。

圖8-2            SSL協(xié)議體系結(jié)構(gòu)

從體系結(jié)構(gòu)圖可以看出，SSL協(xié)議可分為兩層：

q  SSL記錄協(xié)議（SSL Record Protocol）：建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。

q  SSL握手協(xié)議（SSL Handshake Protocol）：建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認證、協(xié)商加密算法、交換加密密鑰等。SSL協(xié)議實際上是SSL握手協(xié)議、SSL修改密文協(xié)議、SSL警告協(xié)議和SSL記錄協(xié)議組成的一個協(xié)議族。下面分別進行介紹。

SSL記錄協(xié)議為SSL連接提供兩種服務(wù)：機密性和報文完整性。

在SSL協(xié)議中，所有的傳輸數(shù)據(jù)都被封裝在記錄中。記錄是由記錄頭和記錄數(shù)據(jù)（長度不為0）組成的。所有的SSL通信都使用SSL記錄層，記錄協(xié)議封裝上層的握手協(xié)議、報警協(xié)議、修改密文協(xié)議。SSL記錄協(xié)議包括記錄頭和記錄數(shù)據(jù)格式的規(guī)定。

SSL記錄協(xié)議定義了要傳輸數(shù)據(jù)的格式，它位于一些可靠的傳輸協(xié)議之上（如TCP），用于各種更高層協(xié)議的封裝。主要完成分組和組合、壓縮和解壓縮，以及消息認證和加密等。

SSL記錄協(xié)議主要操作流程如圖8-3所示。

圖8-3            SSL記錄協(xié)議的操作流程

圖中的五個操作簡單介紹如下：

1）每個上層應(yīng)用數(shù)據(jù)被分成214字節(jié)或更小的數(shù)據(jù)塊。記錄中包含類型、版本號、長度和數(shù)據(jù)字段。

2）壓縮是可選的，并且是無損壓縮，壓縮后內(nèi)容長度的增加不能超過1024字節(jié)。

3）在壓縮數(shù)據(jù)上計算消息認證MAC。

4）對壓縮數(shù)據(jù)及MAC進行加密。

5）增加SSL記錄。

SSL記錄協(xié)議字段的結(jié)構(gòu)如圖8-4所示。

圖8-4            SSL記錄協(xié)議字段的結(jié)構(gòu)

如圖8-4 SSL記錄協(xié)議字段結(jié)構(gòu)主要由內(nèi)容類型、主要版本、次要版本、壓縮長度組成，簡介如下：

1)        內(nèi)容類型（8位）：封裝的高層協(xié)議。

2)        主要版本（8位）：使用的SSL主要版本。對于SSL v3已經(jīng)定義的內(nèi)容類型是握手協(xié)議、警告協(xié)議、改變密碼格式協(xié)議和應(yīng)用數(shù)據(jù)協(xié)議。

3)        次要版本（8位）：使用的SSL次要版本。對于SSL v3.0，值為0。

4)        壓縮長度（16位）：明文數(shù)據(jù)（如果選用壓縮則是壓縮數(shù)據(jù)）以字節(jié)為單位的長度。

SSL報警協(xié)議是用來為對等實體傳遞SSL的相關(guān)警告。如果在通信過程中某一方發(fā)現(xiàn)任何異常,就需要給對方發(fā)送一條警示消息通告。警示消息有兩種：

q   Fatal錯誤,如傳遞數(shù)據(jù)過程中發(fā)現(xiàn)錯誤的MAC,雙方就需要立即中斷會話,同時消除自己緩沖區(qū)相應(yīng)的會話記錄。

q  Warning消息,這種情況,通信雙方通常都只是記錄日志,而對通信過程不造成任何影響。SSL握手協(xié)議可以使得服務(wù)器和客戶能夠相互鑒別對方,協(xié)商具體的加密算法和MAC算法以及保密密鑰,用來保護在SSL記錄中發(fā)送的數(shù)據(jù)。

為了保障SSL傳輸過程的安全性,客戶端和服務(wù)器雙方應(yīng)該每隔一段時間改變加密規(guī)范。所以有了SSL修改密文協(xié)議。SSL修改密文協(xié)議是3個高層的特定協(xié)議之一,也是其中最簡單的一個。在客服端和服務(wù)器完成握手協(xié)議之后,它需要向?qū)Ψ桨l(fā)送相關(guān)消息(該消息只包含一個值為1的單字節(jié))，通知對方隨后的數(shù)據(jù)將用剛剛協(xié)商的密碼規(guī)范算法和關(guān)聯(lián)的密鑰處理，并負責(zé)協(xié)調(diào)本方模塊按照協(xié)商的算法和密鑰工作。

SSL握手協(xié)議被封裝在記錄協(xié)議中，該協(xié)議允許服務(wù)器與客戶機在應(yīng)用程序傳輸和接收數(shù)據(jù)之前互相認證、協(xié)商加密算法和密鑰。在初次建立SSL連接時，服務(wù)器與客戶機交換一系列消息。

這些消息交換能夠?qū)崿F(xiàn)如下操作：

q  客戶機認證服務(wù)器

q  允許客戶機與服務(wù)器選擇雙方都支持的密碼算法

q  可選擇的服務(wù)器認證客戶

q  使用公鑰加密技術(shù)生成共享密鑰

q  建立加密SSL連接

SSL握手協(xié)議報文頭包括三個字段：

q  類型（1字節(jié)）：該字段指明使用的SSL握手協(xié)議報文類型。

q  長度（3字節(jié)）：以字節(jié)為單位的報文長度。

q  內(nèi)容（≥1字節(jié)）：使用的報文的有關(guān)參數(shù)。

SSL握手協(xié)議的報文類型如表8-1所示。

表8-1  SSL握手協(xié)議報文類型

SSL握手協(xié)議過程如圖8-5所示。

圖8-5            SSL握手協(xié)議的過程（帶*的傳輸是可選的，或者與站點相關(guān)的，并不總是發(fā)送的報文）

現(xiàn)在看圖8-5，分步說明SSL握手協(xié)議的全過程：

步驟1      建立安全能力。

客戶機向服務(wù)器發(fā)送client_hello報文，服務(wù)器向客戶機回應(yīng)server_hello報文。建立的安全屬性包括：協(xié)議版本、會話ID、密文族、壓縮方法，同時生成并交換用于防止重放攻擊的隨機數(shù)。密文族參數(shù)包括密鑰交換方法（Deffie-Hellman密鑰交換算法、基于RSA的密鑰交換和另一種實現(xiàn)在Fortezza chip上的密鑰交換）、加密算法（DES、RC4、RC2、3DES等）、MAC算法（MD5或SHA-1）、加密類型（流或分組）等內(nèi)容。

步驟2      認證服務(wù)器和密鑰交換。

在hello報文之后，如果服務(wù)器需要被認證，服務(wù)器將發(fā)送其證書。如果需要，服務(wù)器還要發(fā)送server_key_exchange；然后，服務(wù)器可以向客戶發(fā)送certificate_request請求證書。服務(wù)器總是發(fā)送server_hello_done報文，指示服務(wù)器的hello階段結(jié)束。

步驟3      認證客戶和密鑰交換。

客戶一旦收到服務(wù)器的server_hello_done報文，客戶將檢查服務(wù)器證書的合法性（如果服務(wù)器要求），如果服務(wù)器向客戶請求了證書，客戶必須發(fā)送客戶證書，然后發(fā)送client_key_exchange報文，報文的內(nèi)容依賴于client_hello與server_hello定義的密鑰交換的類型。最后，客戶可能發(fā)送client_verify 報文來校驗客戶發(fā)送的證書，這個報文只能在具有簽名作用的客戶證書之后發(fā)送。

步驟4      結(jié)束。

客戶發(fā)送change_cipher_spec報文并將掛起的CipherSpec復(fù)制到當(dāng)前的CipherSpec。這個報文使用的是修改密文協(xié)議。然后，客戶在新的算法、對稱密鑰和MAC秘密之下立即發(fā)送finished報文。finished報文驗證密鑰交換和鑒別過程是成功的。服務(wù)器對這兩個報文響應(yīng)，發(fā)送自己的change_cipher_spec報文、finished報文。握手結(jié)束，客戶與服務(wù)器可以發(fā)送應(yīng)用層數(shù)據(jù)了。

當(dāng)客戶從服務(wù)器端傳送的證書中獲得相關(guān)信息時，需要檢查以下內(nèi)容來完成對服務(wù)器的認證：

q   時間是否在證書的合法期限內(nèi)；

q   簽發(fā)證書的機關(guān)是否客戶端信任的；

q   簽發(fā)證書的公鑰是否符合簽發(fā)者的數(shù)字簽名；

q   證書中的服務(wù)器域名是否符合服務(wù)器自己真正的域名。

服務(wù)器被驗證成功后，客戶繼續(xù)進行握手過程。

同樣地，服務(wù)器從客戶傳送的證書中獲得相關(guān)信息認證客戶的身份，需要檢查：

q   用戶的公鑰是否符合用戶的數(shù)字簽名；

q   時間是否在證書的合法期限內(nèi)；

q   簽發(fā)證書的機關(guān)是否服務(wù)器信任的；

q   用戶的證書是否被列在服務(wù)器的LDAP里用戶的信息中；

q   得到驗證的用戶是否仍然有權(quán)限訪問請求的服務(wù)器資源。