SSL(Secure Sockets Layer ，安全套接層)，是為網絡通信提供安全及資料完整性的一種安全協定。由Netscape研發，用以保障在Internet上資料傳輸的安全，利用資料加密(Encryption)技術，確定資料在網絡上的傳輸過程中不會被截取及竊聽。
目前幾乎所有浏覽器都支援SSL，但是支援的版本有所不同。從圖8-1中可以看到，IE同時支援SSL 2.0和SSL 3.0兩個版本。
圖8-1 IE支援的SSL版本
事實上各位讀者已經明白了SSL的工作原理，回顧我前面部落格講到的公鑰加密的通信原理，而SSL使用的就是公鑰加密系統。現在完全可以構想基于SSL的資料通信流程。前面說過，SSL是一種協定，本節重點在于協定本身和它是如何工作在各種協定之間來提供安全通信的。
SSL協定位于TCP/IP協定模型的網絡層和應用層之間,使用TCP來提供一種可靠的端到端的安全服務,它使客戶/伺服器應用之間的通信不被攻擊竊聽,并且始終對伺服器進行認證,還可以選擇對客戶進行認證。SSL協定在應用層通信之前就已經完成加密算法、通信密鑰的協商，以及伺服器認證工作,在此之後,應用層協定所傳送的資料都被加密。
SSL協定體系結構如圖8-2所示。
圖8-2 SSL協定體系結構
從體系結構圖可以看出，SSL協定可分為兩層：
q SSL記錄協定（SSL Record Protocol）：建立在可靠的傳輸協定（如TCP）之上，為高層協定提供資料封裝、壓縮、加密等基本功能的支援。
q SSL握手協定（SSL Handshake Protocol）：建立在SSL記錄協定之上，用于在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。SSL協定實際上是SSL握手協定、SSL修改密文協定、SSL警告協定和SSL記錄協定組成的一個協定族。下面分别進行介紹。
SSL記錄協定為SSL連接配接提供兩種服務：機密性和封包完整性。
在SSL協定中，所有的傳輸資料都被封裝在記錄中。記錄是由記錄頭和記錄資料（長度不為0）組成的。所有的SSL通信都使用SSL記錄層，記錄協定封裝上層的握手協定、報警協定、修改密文協定。SSL記錄協定包括記錄頭和記錄資料格式的規定。
SSL記錄協定定義了要傳輸資料的格式，它位于一些可靠的傳輸協定之上（如TCP），用于各種更高層協定的封裝。主要完成分組群組合、壓縮和解壓縮，以及消息認證和加密等。
SSL記錄協定主要操作流程如圖8-3所示。
圖8-3 SSL記錄協定的操作流程
圖中的五個操作簡單介紹如下：
1）每個上層應用資料被分成214位元組或更小的資料塊。記錄中包含類型、版本号、長度和資料字段。
2）壓縮是可選的，并且是無損壓縮，壓縮後内容長度的增加不能超過1024位元組。
3）在壓縮資料上計算消息認證MAC。
4）對壓縮資料及MAC進行加密。
5）增加SSL記錄。
SSL記錄協定字段的結構如圖8-4所示。
圖8-4 SSL記錄協定字段的結構
如圖8-4 SSL記錄協定字段結構主要由内容類型、主要版本、次要版本、壓縮長度組成，簡介如下：
1) 内容類型（8位）：封裝的高層協定。
2) 主要版本（8位）：使用的SSL主要版本。對于SSL v3已經定義的内容類型是握手協定、警告協定、改變密碼格式協定和應用資料協定。
3) 次要版本（8位）：使用的SSL次要版本。對于SSL v3.0，值為0。
4) 壓縮長度（16位）：明文資料（如果選用壓縮則是壓縮資料）以位元組為機關的長度。
說明 已經定義的内容類型是握手協定、警告協定、修改密文協定。
SSL報警協定是用來為對等實體傳遞SSL的相關警告。如果在通信過程中某一方發現任何異常,就需要給對方發送一條警示消息通告。警示消息有兩種：
q Fatal錯誤,如傳遞資料過程中發現錯誤的MAC,雙方就需要立即中斷會話,同時消除自己緩沖區相應的會話記錄。
q Warning消息,這種情況,通信雙方通常都隻是記錄日志,而對通信過程不造成任何影響。SSL握手協定可以使得伺服器和客戶能夠互相鑒别對方,協商具體的加密算法和MAC算法以及保密密鑰,用來保護在SSL記錄中發送的資料。
為了保障SSL傳輸過程的安全性,用戶端和伺服器雙方應該每隔一段時間改變加密規範。是以有了SSL修改密文協定。SSL修改密文協定是3個高層的特定協定之一,也是其中最簡單的一個。在客服端和伺服器完成握手協定之後,它需要向對方發送相關消息(該消息隻包含一個值為1的單位元組)，通知對方随後的資料将用剛剛協商的密碼規範算法和關聯的密鑰處理，并負責協調本方子產品按照協商的算法和密鑰工作。
SSL握手協定被封裝在記錄協定中，該協定允許伺服器與客戶機在應用程式傳輸和接收資料之前互相認證、協商加密算法和密鑰。在初次建立SSL連接配接時，伺服器與客戶機交換一系列消息。
這些消息交換能夠實作如下操作：
q 客戶機認證伺服器
q 允許客戶機與伺服器選擇雙方都支援的密碼算法
q 可選擇的伺服器認證客戶
q 使用公鑰加密技術生成共享密鑰
q 建立加密SSL連接配接
SSL握手協定封包頭包括三個字段：
q 類型（1位元組）：該字段指明使用的SSL握手協定封包類型。
q 長度（3位元組）：以位元組為機關的封包長度。
q 内容（≥1位元組）：使用的封包的有關參數。
SSL握手協定的封包類型如表8-1所示。
表8-1 SSL握手協定封包類型
封包類型
參數
hello_request
空
client_hello
版本、随機數、會話ID、密文族、壓縮方法
server_hello
certificate
x.509V3證書鍊
server_key_exchange
參數、簽名
certificate_request
類型、授權
server_done
certificate_verify
簽名
client_key_exchange
finished
Hash值
SSL握手協定過程如圖8-5所示。
圖8-5 SSL握手協定的過程（帶*的傳輸是可選的，或者與站點相關的，并不總是發送的封包）
現在看圖8-5，分步說明SSL握手協定的全過程：
步驟1 建立安全能力。
客戶機向伺服器發送client_hello封包，伺服器向客戶機回應server_hello封包。建立的安全屬性包括：協定版本、會話ID、密文族、壓縮方法，同時生成并交換用于防止重播攻擊的随機數。密文族參數包括密鑰交換方法（Deffie-Hellman密鑰交換算法、基于RSA的密鑰交換和另一種實作在Fortezza chip上的密鑰交換）、加密算法（DES、RC4、RC2、3DES等）、MAC算法（MD5或SHA-1）、加密類型（流或分組）等内容。
步驟2 認證伺服器和密鑰交換。
在hello封包之後，如果伺服器需要被認證，伺服器将發送其證書。如果需要，伺服器還要發送server_key_exchange；然後，伺服器可以向客戶發送certificate_request請求證書。伺服器總是發送server_hello_done封包，訓示伺服器的hello階段結束。
步驟3 認證客戶和密鑰交換。
客戶一旦收到伺服器的server_hello_done封包，客戶将檢查伺服器證書的合法性（如果伺服器要求），如果伺服器向客戶請求了證書，客戶必須發送客戶證書，然後發送client_key_exchange封包，封包的内容依賴于client_hello與server_hello定義的密鑰交換的類型。最後，客戶可能發送client_verify 封包來校驗客戶發送的證書，這個封包隻能在具有簽名作用的客戶證書之後發送。
步驟4 結束。
客戶發送change_cipher_spec封包并将挂起的CipherSpec複制到目前的CipherSpec。這個封包使用的是修改密文協定。然後，客戶在新的算法、對稱密鑰和MAC秘密之下立即發送finished封包。finished封包驗證密鑰交換和鑒别過程是成功的。伺服器對這兩個封包響應，發送自己的change_cipher_spec封包、finished封包。握手結束，客戶與伺服器可以發送應用層資料了。
當客戶從伺服器端傳送的證書中獲得相關資訊時，需要檢查以下内容來完成對伺服器的認證：
q 時間是否在證書的合法期限内；
q 簽發證書的機關是否用戶端信任的；
q 簽發證書的公鑰是否符合簽發者的數字簽名；
q 證書中的伺服器域名是否符合伺服器自己真正的域名。
伺服器被驗證成功後，客戶繼續進行握手過程。
同樣地，伺服器從客戶傳送的證書中獲得相關資訊認證客戶的身份，需要檢查：
q 使用者的公鑰是否符合使用者的數字簽名；
q 簽發證書的機關是否伺服器信任的；
q 使用者的證書是否被列在伺服器的LDAP裡使用者的資訊中；
q 得到驗證的使用者是否仍然有權限通路請求的伺服器資源。
---------------注：本文部分内容改編自《.NET 安全揭秘》
本文轉自玄魂部落格園部落格，原文連結：http://www.cnblogs.com/xuanhun/archive/2012/06/23/2559607.html，如需轉載請自行聯系原作者