- 黑客攻防從入門到精通(Web技術實戰篇)
- 明月工作室 王棟
- 5689字
- 2020-05-22 18:52:19
4.1 Web驗證機制實現技術——SSL身份驗證
前面已經提到過了,Web應用程序常見的驗證方式有基于HTML表單的驗證,口令卡或者硬件key,或者SSL證書等,但是到目前為止,Web應用程序中最受青睞的驗證機制還是基于SSL機制的驗證。SSL身份驗證憑借著其安全性能高、支持各種應用層協議、部署簡單等優勢,成為驗證機制的主流技術。
4.1.1 SSL身份驗證產生背景
基于萬維網的電子商務和網上銀行等新興應用,極大地方便了人們的日常生活,受到人們的青睞。由于這些應用都需要在網絡上進行在線交易,它們對網絡通信的安全性提出了更高的要求。傳統的萬維網協議HTTP不具備安全機制——采用明文的形式傳輸數據、不能驗證通信雙方的身份、無法防止傳輸的數據被篡改等,導致HTTP無法滿足電子商務和網上銀行等應用的安全性要求。
Netscape公司提出的安全協議SSL,利用數據加密、身份驗證和消息完整性驗證機制,為網絡上數據的傳輸提供安全性保證。SSL可以為HTTP提供安全連接,從而很大程度上改善了萬維網的安全性問題。
采用了SSL驗證機制的Web應用程序,項目的管理和分配的成本會變得比一般程序要高,但SSL驗證機制憑借著以下優點,仍然獲得了大部分應用程序的青睞。
(1)提供較高的安全性保證。
SSL利用數據加密、身份驗證和消息完整性驗證機制,保證網絡上數據傳輸的安全性。
(2)支持各種應用層協議。
雖然SSL設計的初衷是解決萬維網安全性問題,但是由于SSL位于應用層和傳輸層之間,它可以為任何基于TCP等可靠連接的應用層協議提供安全性保證。
(3)部署簡單。
目前SSL已經成為網絡中用來鑒別網站和網頁瀏覽者身份,在瀏覽器使用者及Web服務器之間進行加密通信的全球化標準。SSL協議已被集成到大部分的瀏覽器中,如IE、Netscape、Firefox等,這就意味著幾乎任意一臺裝有瀏覽器的計算機都支持SSL連接,不需要安裝額外的客戶端軟件。
4.1.2 SSL身份驗證協議安全機制
SSL協議實現的安全機制主要包括三點,分別為數據傳輸的機密性、身份驗證機制和消息完整性驗證。
1.數據傳輸的機密性
數據傳輸的機密性主要是指利用對稱密鑰算法對傳輸的數據進行加密。
網絡上傳輸的數據很容易被非法用戶竊取,SSL采用在通信雙方之間建立加密通道的方法保證數據傳輸的機密性。
所謂加密通道是指發送方在發送數據前,使用加密算法和加密密鑰對數據進行加密,然后將數據發送給對方;接收方接收到數據后,利用解密算法和解密密鑰從密文中獲取明文。沒有解密密鑰的第三方,無法將密文恢復為明文,從而保證數據傳輸的機密性。
加、解密算法分為兩類。
(1)對稱密鑰算法。數據加密和解密時使用相同的密鑰。
(2)非對稱密鑰算法。數據加密和解密時使用不同的密鑰,一個是公開的公鑰,一個是由用戶秘密保存的私鑰。利用公鑰(或私鑰)加密的數據只能用相應的私鑰(或公鑰)才能解密。
與非對稱密鑰算法相比,對稱密鑰算法具有計算速度快的優點,通常用于對大量信息進行加密(如對所有報文加密);而非對稱密鑰算法,一般用于數字簽名和對較少的信息進行加密。
SSL加密通道上的數據加、解密使用對稱密鑰算法,目前主要支持的算法有DES、3DES、AES等,這些算法都可以有效地防止交互數據被破解。
對稱密鑰算法要求解密密鑰和加密密鑰完全一致。因此,利用對稱密鑰算法加密傳輸數據之前,需要在通信兩端部署相同的密鑰。對稱密鑰的部署方法請參考下文。
2.身份驗證機制
身份驗證機制是指基于證書利用數字簽名方法對服務器和客戶端進行身份驗證,其中客戶端的身份驗證是可選的。
電子商務和網上銀行等應用中必須保證要登錄的Web服務器是真實的,以免重要信息被非法竊取。SSL利用數字簽名來驗證通信對端的身份。
非對稱密鑰算法可以用來實現數字簽名。由于通過私鑰加密后的數據只能利用對應的公鑰進行解密,因此根據解密是否成功,就可以判斷發送者的身份,如同發送者對數據進行了“簽名”。例如,Alice使用自己的私鑰對一段固定的信息加密后發給Bob, Bob利用Alice的公鑰解密,如果解密結果與固定信息相同,那么就能夠確認信息的發送者為Alice,這個過程就稱為數字簽名。
SSL客戶端必須驗證SSL服務器的身份,SSL服務器是否驗證SSL客戶端的身份則由SSL服務器決定。SSL客戶端和SSL服務器的身份驗證過程,請參考下文。
使用數字簽名驗證身份時,需要確保被驗證者的公鑰是真實的,否則,非法用戶可能會冒充被驗證者與驗證者通信。如圖4-1所示,Cindy冒充Bob,將自己的公鑰發給Alice,并利用自己的私鑰計算出簽名發送給Alice, Alice利用“Bob”的公鑰(實際上為Cindy的公鑰)成功驗證該簽名,則Alice認為Bob的身份驗證成功,而實際上與Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的機制保證公鑰的真實性,詳細介紹請參考下文。

圖4-1 偽造公鑰技術原理
3.消息完整性驗證
消息完整性驗證是指消息傳輸過程中使用MAC算法來檢驗消息的完整性。
為了避免網絡中傳輸的數據被非法篡改,SSL利用基于MD5或SHA的MAC算法來保證消息的完整性。
MAC算法是在密鑰參與下的數據摘要算法,能將密鑰和任意長度的數據轉換為固定長度的數據。利用MAC算法驗證消息完整性的過程如圖4-2所示。發送者在密鑰的參與下,利用MAC算法計算出消息的MAC值,并將其加在消息之后發送給接收者。接收者利用同樣的密鑰和MAC算法計算出消息的MAC值,并與接收到的MAC值比較。如果二者相同,則報文沒有改變;否則,報文在傳輸過程中被修改,接收者將丟棄該報文。

圖4-2 MAC算法示意圖
MAC算法具有以下特征,使其能夠用來驗證消息的完整性。
(1)消息的任何改變都會引起輸出的固定長度數據產生變化。通過比較MAC值,可以保證接收者能夠發現消息的改變。
(2)MAC算法需要密鑰的參與,因此沒有密鑰的非法用戶在改變消息的內容后,無法添加正確的MAC值,從而保證非法用戶無法隨意修改消息內容。
MAC算法要求通信雙方具有相同的密鑰,否則MAC值驗證將會失敗。因此,利用MAC算法驗證消息完整性之前,需要在通信兩端部署相同的密鑰。MAC密鑰的部署方法請參考下文。
4.1.3 利用非對稱密鑰算法保證密鑰本身的安全
對稱密鑰算法和MAC算法要求通信雙方具有相同的密鑰,否則解密或MAC值驗證將失敗。因此,要建立加密通道或驗證消息完整性,必須先在通信雙方部署一致的密鑰。
SSL利用非對稱密鑰算法加密密鑰的方法實現密鑰交換,保證第三方無法獲取該密鑰。如圖4-3所示,SSL客戶端(如Web瀏覽器)利用SSL服務器(如Web服務器)的公鑰加密密鑰,將加密后的密鑰發送給SSL服務器,只有擁有對應私鑰的SSL服務器才能從密文中獲取原始的密鑰。SSL通常采用RSA算法加密傳輸密鑰。

4-3 密鑰交換示意圖
(1)實際上,SSL客戶端發送給SSL服務器的密鑰不能直接用來加密數據或計算MAC值,該密鑰是用來計算對稱密鑰和MAC密鑰的信息,稱為premaster secret。SSL客戶端和SSL服務器利用premaster secret計算出相同的主密鑰(master secret),再利用master secret生成用于對稱密鑰算法、MAC算法等的密鑰。premaster secret是計算對稱密鑰、MAC算法密鑰的關鍵。
(2)用來實現密鑰交換的算法稱為密鑰交換算法。非對稱密鑰算法RSA用于密鑰交換時,也可以稱之為密鑰交換算法。
4.1.4 利用PKI保證公鑰的真實性
PKI通過數字證書來發布用戶的公鑰,并提供了驗證公鑰真實性的機制。數字證書(簡稱證書)是一個包含用戶的公鑰及其身份信息的文件,證明了用戶與公鑰的關聯。數字證書由權威機構——CA簽發,并由CA保證數字證書的真實性。
SSL客戶端把密鑰加密傳遞給SSL服務器之前,SSL服務器需要將從CA獲取的證書發送給SSL客戶端,SSL客戶端通過PKI判斷該證書的真實性。如果該證書確實屬于SSL服務器,則利用該證書中的公鑰加密密鑰,發送給SSL服務器。
驗證SSL服務器/SSL客戶端的身份之前,SSL服務器/SSL客戶端需要將從CA獲取的證書發送給對端,對端通過PKI判斷該證書的真實性。如果該證書確實屬于SSL服務器/SSL客戶端,則對端利用該證書中的公鑰驗證SSL服務器/SSL客戶端的身份。
4.1.5 SSL驗證協議工作過程
1.SSL的分層結構
如圖4-4所示,SSL位于應用層和傳輸層之間,它可以為任何基于TCP等可靠連接的應用層協議提供安全性保證。SSL協議本身分為兩層:

圖4-4 SSL協議分層
上層為SSL握手協議(SSL handshake protocol)、SSL密碼變化協議(SSL change cipher spec protocol)和SSL警告協議(SSL alert protocol)。底層為SSL記錄協議(SSL record protocol)。
(1)SSL握手協議:是SSL協議非常重要的組成部分,用來協商通信過程中使用的加密套件(加密算法、密鑰交換算法和MAC算法等)、在服務器和客戶端之間安全地交換密鑰、實現服務器和客戶端的身份驗證。
(2)SSL密碼變化協議:客戶端和服務器端通過密碼變化協議通知對端,隨后的報文都將使用新協商的加密套件和密鑰進行保護和傳輸。
(3)SSL警告協議:用來向通信對端報告警告信息,消息中包含警告的嚴重級別和描述。
(4)SSL記錄協議:主要負責對上層的數據(SSL握手協議、SSL密碼變化協議、SSL警告協議和應用層協議報文)進行分塊、計算并添加MAC值、加密,并把處理后的記錄塊傳輸給對端。
2.SSL握手過程
SSL通過握手過程在客戶端和服務器之間協商會話參數,并建立會話。會話包含的主要參數有會話ID、對方的證書、加密套件(密鑰交換算法、數據加密算法和MAC算法等)以及主密鑰(master secret)。通過SSL會話傳輸的數據,都將采用該會話的主密鑰和加密套件進行加密、計算MAC等處理。
不同情況下,SSL握手過程存在差異。下面將分別描述三種情況下的握手過程。
(1)只驗證服務器的SSL握手過程。
如圖4-5所示,只需要驗證SSL服務器身份,不需要驗證SSL客戶端身份時,SSL的握手過程如下。

圖4-5 只驗證服務器的SSL握手過程
① SSL客戶端通過Client Hello消息將它支持的SSL版本、加密算法、密鑰交換算法、MAC算法等信息發送給SSL服務器。
② SSL服務器確定本次通信采用的SSL版本和加密套件,并通過Server Hello消息通知給SSL客戶端。如果SSL服務器允許SSL客戶端在以后的通信中重用本次會話,則SSL服務器會為本次會話分配會話ID,并通過Server Hello消息發送給SSL客戶端。
③ SSL服務器將攜帶自己公鑰信息的數字證書通過Certificate消息發送給SSL客戶端。
④ SSL服務器發送Server Hello Done消息,通知SSL客戶端版本和加密套件協商結束,開始進行密鑰交換。
⑤ SSL客戶端驗證SSL服務器的證書合法后,利用證書中的公鑰加密SSL客戶端隨機生成的premaster secret,并通過Client Key Exchange消息發送給SSL服務器。
⑥ SSL客戶端發送Change Cipher Spec消息,通知SSL服務器后續報文將采用協商好的密鑰和加密套件進行加密和MAC計算。
⑦ SSL客戶端計算已交互的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值,利用協商好的密鑰和加密套件處理Hash值(計算并添加MAC值、加密等),并通過Finished消息發送給SSL服務器。SSL服務器利用同樣的方法計算已交互的握手消息的Hash值,并與Finished消息的解密結果比較,如果二者相同,且MAC值驗證成功,則證明密鑰和加密套件協商成功。
⑧ 同樣地,SSL服務器發送Change Cipher Spec消息,通知SSL客戶端后續報文將采用協商好的密鑰和加密套件進行加密和MAC計算。
⑨ SSL服務器計算已交互的握手消息的Hash值,利用協商好的密鑰和加密套件處理Hash值(計算并添加MAC值、加密等),并通過Finished消息發送給SSL客戶端。SSL客戶端利用同樣的方法計算已交互的握手消息的Hash值,并與Finished消息的解密結果比較,如果二者相同,且MAC值驗證成功,則證明密鑰和加密套件協商成功。
SSL客戶端接收到SSL服務器發送的Finished消息后,如果解密成功,則可以判斷SSL服務器是數字證書的擁有者,即SSL服務器身份驗證成功,因為只有擁有私鑰的SSL服務器才能從Client Key Exchange消息中解密得到premaster secret,從而間接地實現了SSL客戶端對SSL服務器的身份驗證。
注意
①Change Cipher Spec消息屬于SSL密碼變化協議,其他握手過程交互的消息均屬于SSL握手協議,統稱為SSL握手消息。
②計算Hash值,指的是利用Hash算法(MD5或SHA)將任意長度的數據轉換為固定長度的數據。
(2)驗證服務器和客戶端的SSL握手過程。
SSL客戶端的身份驗證是可選的,由SSL服務器決定是否驗證SSL客戶端的身份。如圖4-6所示,如果SSL服務器驗證SSL客戶端身份,則SSL服務器和SSL客戶端除了交互“SSL握手過程”中的消息協商密鑰和加密套件外,還需要進行以下操作。

圖4-6 驗證服務器和客戶端的SSL握手過程
① SSL服務器發送Certificate Request消息,請求SSL客戶端將其證書發送給SSL服務器。
② SSL客戶端通過Certificate消息將攜帶自己公鑰的證書發送給SSL服務器。SSL服務器驗證該證書的合法性。
③ SSL客戶端計算已交互的握手消息、主密鑰的Hash值,利用自己的私鑰對其進行加密,并通過Certificate Verify消息發送給SSL服務器。
④ SSL服務器計算已交互的握手消息、主密鑰的Hash值,利用SSL客戶端證書中的公鑰解密Certificate Verify消息,并將解密結果與計算出的Hash值比較。如果二者相同,則SSL客戶端身份驗證成功。
(3)恢復原有會話的SSL握手過程。
協商會話參數、建立會話的過程中,需要使用非對稱密鑰算法來加密密鑰、驗證通信對端的身份,計算量較大,占用了大量的系統資源。如圖4-7所示,為了簡化SSL握手過程,SSL允許重用已經協商過的會話,具體過程如下。

圖4-7 恢復原有會話的SSL握手過程
① SSL客戶端發送Client Hello消息,消息中的會話ID設置為計劃重用的會 話的ID。
② SSL服務器如果允許重用該會話,則通過在Server Hello消息中設置相同的會話ID來應答。這樣,SSL客戶端和SSL服務器就可以利用原有會話的密鑰和加密套件,不必重新協商。
③ SSL客戶端發送Change Cipher Spec消息,通知SSL服務器后續報文將采用原有會話的密鑰和加密套件進行加密和MAC計算。
④ SSL客戶端計算已交互的握手消息的Hash值,利用原有會話的密鑰和加密套件處理Hash值,并通過Finished消息發送給SSL服務器,以便SSL服務器判斷密鑰和加密套件是否正確。
⑤ 同樣地,SSL服務器發送Change Cipher Spec消息,通知SSL客戶端后續報文將采用原有會話的密鑰和加密套件進行加密和MAC計算。
⑥ SSL服務器計算已交互的握手消息的Hash值,利用原有會話的密鑰和加密套件處理Hash值,并通過Finished消息發送給SSL客戶端,以便SSL客戶端判斷密鑰和加密套件是否正確。
4.1.6 Web應用程序應用SSL驗證機制
1.HTTPS
HTTPS是基于SSL安全連接的HTTP協議。HTTPS通過SSL提供的數據加密、身份驗證和消息完整性驗證等安全機制,為Web訪問提供了安全性保證,廣泛應用于網上銀行、電子商務等領域。
圖4-8為HTTPS在網上銀行中的應用。某銀行為了方便客戶,提供了網上銀行業務,客戶可以通過訪問銀行的W eb服務器進行賬戶查詢、轉賬等。通過在客戶和銀行的Web服務器之間建立SSL連接,可以保證客戶的信息不被非法竊取。

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

圖4-9 SSL VPN的典型組網環境
- RESTful Java Web Services Security
- Web漏洞分析與防范實戰:卷1
- 數據恢復方法及案例分析
- Mobile Forensics Cookbook
- 深入淺出隱私計算:技術解析與應用實踐
- 網絡安全三十六計:人人該懂的防黑客技巧
- 諸神之眼:Nmap網絡安全審計技術揭秘
- Spring Security(Third Edition)
- 人工智能安全(精裝版)
- 網絡安全實戰詳解(企業專供版)
- 企業數據安全防護指南
- Mastering Malware Analysis
- 黑客攻防與電腦安全從新手到高手(超值版)
- 5G網絡安全規劃與實踐
- Hands-On Bug Hunting for Penetration Testers