SSL工作原理


SSL工作原理

http://blog.csdn.net/it_man/article/details/24698093

 

公鑰和私鑰  

一直以來對公鑰和私鑰都理解得不是很透徹,感覺到模棱兩可。今天在網上找了半天,通過查看對這個密鑰對的理解,總算弄清楚了。       公鑰和私鑰就是俗稱的不對稱加密方式,是從以前的對稱加密(使用用戶名與密碼)方式的提高。用電子郵件的方式說明一下原理。       使用公鑰與私鑰的目的就是實現安全的電子郵件,必須實現如下目的:       1. 我發送給你的內容必須加密,在郵件的傳輸過程中不能被別人看到。       2. 必須保證是我發送的郵件,不是別人冒充我的。       要達到這樣的目標必須發送郵件的兩人都有公鑰和私鑰。       公鑰,就是給大家用的,你可以通過電子郵件發布,可以通過網站讓別人下載,公鑰其實是用來加密/驗章用的。私鑰,就是自己的,必須非常小心保存,最好加上 密碼,私鑰是用來解密/簽章,首先就Key的所有權來說,私鑰只有個人擁有。公鑰與私鑰的作用是:用公鑰加密的內容只能用私鑰解密,用私鑰加密的內容只能 用公鑰解密。       比如說,我要給你發送一個加密的郵件。首先,我必須擁有你的公鑰,你也必須擁有我的公鑰。       首先,我用你的公鑰給這個郵件加密,這樣就保證這個郵件不被別人看到,而且保證這個郵件在傳送過程中沒有被修改。你收到郵件后,用你的私鑰就可以解密,就能看到內容。       其次我用我的私鑰給這個郵件加密,發送到你手里后,你可以用我的公鑰解密。因為私鑰只有我手里有,這樣就保證了這個郵件是我發送的。       當A->B資料時,A會使用B的公鑰加密,這樣才能確保只有B能解開,否則普羅大眾都能解開加密的訊息,就是去了資料的保密性。驗證方面則是使用簽 驗章的機制,A傳資料給大家時,會以自己的私鑰做簽章,如此所有收到訊息的人都可以用A的公鑰進行驗章,便可確認訊息是由 A 發出來的了。

   數字證書的原理

   數字證書采用公鑰體制,即利用一對互相匹配的密鑰進行加密、解密。每個用戶自己設定一把特定的僅為本人所知的私有密鑰(私鑰),用它進行解密和簽名;同時 設定一把公共密鑰(公鑰)並由本人公開,為一組用戶所共享,用於加密和驗證簽名。當發送一份保密文件時,發送方使用接收方的公鑰對數據加密,而接收方則使 用自己的私鑰解密,這樣信息就可以安全無誤地到達目的地了。通過數字的手段保證加密過程是一個不可逆過程,即只有用私有密鑰才能解密. 在公開密鑰密碼體制中,常用的一種是RSA體制。 用戶也可以采用自己的私鑰對信息加以處理,由於密鑰僅為本人所有,這樣就產生了別人無法生成的文件,也就形成了數字簽名。采用數字簽名,能夠確認以下兩點: (1)保證信息是由簽名者自己簽名發送的,簽名者不能否認或難以否認; (2)保證信息自簽發后到收到為止未曾作過任何修改,簽發的文件是真實文件。

 

 

SSL 是一個安全協議,它提供使用 TCP/IP 的通信應用程序間的隱私與完整性。因特網的 超文本傳輸協議 (HTTP)使用 SSL 來實現安全的通信。

在客戶端與服務器間傳輸的數據是通過使用對稱算法(如 DES 或 RC4)進行加密的。公用密鑰算法(通常為 RSA)是用來獲得加密密鑰交換和數字簽名的,此算法使用服務器的SSL數字證書中的公用密鑰。有了服務器的SSL數字證書,客戶端也可以驗證服務器的身 份。SSL 協議的版本 1 和 2 只提供服務器認證。版本 3 添加了客戶端認證,此認證同時需要客戶端和服務器的數字證書。

SSL 握手/

SSL 連接總是由客戶端啟動的。在SSL 會話開始時執行 SSL 握手。此握手產生會話的密碼參數。關於如何處理 SSL 握手的簡單概述,如下圖所示。此示例假設已在 Web 瀏覽器 和 Web 服務器間建立了 SSL 連接。

(1) 客戶端發送列出客戶端密碼能力的客戶端“您好”消息(以客戶端首選項順序排序),如 SSL 的版本、客戶端支持的密碼對和客戶端支持的數據壓縮方法。消息也包含 28 字節的隨機數。

(2) 服務器以服務器“您好”消息響應,此消息包含密碼方法(密碼對)和由服務器選擇的數據壓縮方法,以及會話標識和另一個隨機數。

注意:客戶端和服務器至少必須支持一個公共密碼對,否則握手失敗。服務器一般選擇最大的公共密碼對。

(3) 服務器發送其SSL數字證書。(服務器使用帶有 SSL 的 X.509 V3 數字證書。)

如果服務器使用 SSL V3,而服務器應用程序(如 Web 服務器)需要數字證書進行客戶端認證,則客戶端會發出“數字證書請求”消息。在 “數字證書請求”消息中,服務器發出支持的客戶端數字證書類型的列表和可接受的CA的名稱。

(4) 服務器發出服務器“您好完成”消息並等待客戶端響應。

(5) 一接到服務器“您好完成”消息,客戶端( Web 瀏覽器)將驗證服務器的SSL數字證書的有效性並檢查服務器的“你好”消息參數是否可以接受。

如果服務器請求客戶端數字證書,客戶端將發送其數字證書;或者,如果沒有合適的數字證書是可用的,客戶端將發送“沒有數字證書”警告。此警告僅僅是警告而已,但如果客戶端數字證書認證是強制性的話,服務器應用程序將會使會話失敗。

(6) 客戶端發送“客戶端密鑰交換”消息。

此消息包含 pre-master secret (一個用在對稱加密密鑰生成中的 46 字節的隨機數字),和 消息認證代碼 ( MAC )密鑰(用服務器的公用密鑰加密的)。

如果客戶端發送客戶端數字證書給服務器,客戶端將發出簽有客戶端的專用密鑰的“數字證書驗證”消息。通過驗證此消息的簽名,服務器可以顯示驗證客戶端數字證書的所有權。

注意: 如果服務器沒有屬於數字證書的專用密鑰,它將無法解密 pre-master 密碼,也無法創建對稱加密算法的正確密鑰,且握手將失敗。

(7) 客戶端使用一系列加密運算將 pre-master secret 轉化為 master secret ,其中將派生出所有用於加密和消息認證的密鑰。然后,客戶端發出“更改密碼規范” 消息將服務器轉換為新協商的密碼對。客戶端發出的下一個消息(“未完成”的消息)為用此密碼方法和密鑰加密的第一條消息。

(8) 服務器以自己的“更改密碼規范”和“已完成”消息響應。

(9) SSL 握手結束,且可以發送加密的應用程序數據。

 

 

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

虛擬專有網絡

 


 

1  概述

1.1  產生背景

基於萬維網的電子商務和網上銀行等新興應用,極大地方便了人們的日常生活,受到人們的青睞。由於這些應用都需要在網絡上進行在線交易,它們對網絡通信的安全性提出了更高的要求。傳統的萬維網協議HTTP不具備安全機制——采用明文的形式傳輸數據、不能驗證通信雙方的身份、無法防止傳輸的數據被篡改等,導致HTTP無法滿足電子商務和網上銀行等應用的安全性要求。

Netscape公司提出的安全協議SSL,利用數據加密、身份驗證和消息完整性驗證機制,為網絡上數據的傳輸提供安全性保證。SSL可以為HTTP提供安全連接,從而很大程度上改善了萬維網的安全性問題。

1.2  技術優點

SSL具有如下優點:

l              提供較高的安全性保證。SSL利用數據加密、身份驗證和消息完整性驗證機制,保證網絡上數據傳輸的安全性。

l              支持各種應用層協議。雖然SSL設計的初衷是為了解決萬維網安全性問題,但是由於SSL位於應用層和傳輸層之間,它可以為任何基於TCP等可靠連接的應用層協議提供安全性保證。

l              部署簡單。目前SSL已經成為網絡中用來鑒別網站和網頁瀏覽者身份,在瀏覽器使用者及Web服務器之間進行加密通信的全球化標准。SSL協議已被集成到大部分的瀏覽器中,如IE、Netscape、Firefox等。這就意味着幾乎任意一台裝有瀏覽器的計算機都支持SSL連接,不需要安裝額外的客戶端軟件。

2  協議安全機制

SSL協議實現的安全機制包括:

l              數據傳輸的機密性:利用對稱密鑰算法對傳輸的數據進行加密。

l              身份驗證機制:基於證書利用數字簽名方法對服務器和客戶端進行身份驗證,其中客戶端的身份驗證是可選的。

l              消息完整性驗證:消息傳輸過程中使用MAC算法來檢驗消息的完整性。

2.1  數據傳輸的機密性

網絡上傳輸的數據很容易被非法用戶竊取,SSL采用在通信雙方之間建立加密通道的方法保證數據傳輸的機密性。

所謂加密通道,是指發送方在發送數據前,使用加密算法和加密密鑰對數據進行加密,然后將數據發送給對方;接收方接收到數據后,利用解密算法和解密密鑰從密文中獲取明文。沒有解密密鑰的第三方,無法將密文恢復為明文,從而保證數據傳輸的機密性。

加解密算法分為兩類:

l              對稱密鑰算法:數據加密和解密時使用相同的密鑰。

l              非對稱密鑰算法:數據加密和解密時使用不同的密鑰,一個是公開的公鑰,一個是由用戶秘密保存的私鑰。利用公鑰(或私鑰)加密的數據只能用相應的私鑰(或公鑰)才能解密。

與非對稱密鑰算法相比,對稱密鑰算法具有計算速度快的優點,通常用於對大量信息進行加密(如對所有報文加密);而非對稱密鑰算法,一般用於數字簽名和對較少的信息進行加密。

SSL加密通道上的數據加解密使用對稱密鑰算法,目前主要支持的算法有DES、3DES、AES等,這些算法都可以有效地防止交互數據被竊聽。

對稱密鑰算法要求解密密鑰和加密密鑰完全一致。因此,利用對稱密鑰算法加密傳輸數據之前,需要在通信兩端部署相同的密鑰。對稱密鑰的部署方法請參見“2.4  利用非對稱密鑰算法保證密鑰本身的安全”。

2.2  身份驗證機制

電子商務和網上銀行等應用中必須保證要登錄的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 偽造公鑰

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所示,SSL客戶端(如Web瀏覽器)利用SSL服務器(如Web服務器)的公鑰加密密鑰,將加密后的密鑰發送給SSL服務器,只有擁有對應私鑰的SSL服務器才能從密文中獲取原始的密鑰。SSL通常采用RSA算法加密傳輸密鑰。

圖3 密鑰交換示意圖

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保證公鑰的真實性”。

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客戶端的身份。

3  協議工作過程

3.1  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值、加密,並把處理后的記錄塊傳輸給對端。

3.2  SSL握手過程

SSL通過握手過程在客戶端和服務器之間協商會話參數,並建立會話。會話包含的主要參數有會話ID、對方的證書、加密套件(密鑰交換算法、數據加密算法和MAC算法等)以及主密鑰(master secret)。通過SSL會話傳輸的數據,都將采用該會話的主密鑰和加密套件進行加密、計算MAC等處理。

不同情況下,SSL握手過程存在差異。下面將分別描述以下三種情況下的握手過程:

l              只驗證服務器的SSL握手過程

l              驗證服務器和客戶端的SSL握手過程

l              恢復原有會話的SSL握手過程

3.2.1  只驗證服務器的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)將任意長度的數據轉換為固定長度的數據。

 

3.2.2  驗證服務器和客戶端的SSL握手過程

圖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客戶端身份驗證成功。

3.2.3  恢復原有會話的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客戶端判斷密鑰和加密套件是否正確。

4  典型組網應用

4.1  HTTPS

HTTPS是基於SSL安全連接的HTTP協議。HTTPS通過SSL提供的數據加密、身份驗證和消息完整性驗證等安全機制,為Web訪問提供了安全性保證,廣泛應用於網上銀行、電子商務等領域。

圖8為HTTPS在網上銀行中的應用。某銀行為了方便客戶,提供了網上銀行業務,客戶可以通過訪問銀行的Web服務器進行帳戶查詢、轉帳等。通過在客戶和銀行的Web服務器之間建立SSL連接,可以保證客戶的信息不被非法竊取。

圖8 HTTPS在網上銀行中的應用

4.2  SSL VPN

SSL VPN是以SSL為基礎的VPN技術,利用SSL提供的安全機制,為用戶遠程訪問公司內部網絡提供了安全保證。如圖9所示,SSL VPN通過在遠程接入用戶和SSL VPN網關之間建立SSL安全連接,允許用戶通過各種Web瀏覽器,各種網絡接入方式,在任何地方遠程訪問企業網絡資源,並能夠保證企業網絡的安全,保護企業內部信息不被竊取。

圖9 SSL VPN的典型組網環境


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM