"SSL"協議對於黑客技術學習,是必須要掌握的,因為它在很多應用通信中無處不在。

"SSL"這個名詞，可能大家沒怎麼聽說過，但是它的一個應用大家肯定都熟悉，那就是"HTTPS"！

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

"SSL"是不是很牛！今天我就給大家以本篇文章內容詳細解析一下"SSL"安全協議！

一、"SSL"簡介

1、基本定義

安全套接字（Secure Socket Layer，SSL）協議是Web瀏覽器與Web服務器之間安全交換信息的協議，提供兩個基本的安全服務：鑑別與保密。

2、產生背景

基於因特網的電子商務和網上銀行等新興應用，極大地方便了人們的日常生活，受到人們的青睞。由於這些應用都需要在網絡上進行在線交易，它們對網絡通 信的安全性提出了更高的要求。

傳統的因特網協議HTTP不具備安全機制——採用明文的形式傳輸數據、不能驗證通信雙方的身份、無法防止傳輸的數據被篡改 等，導致HTTP無法滿足電子商務和網上銀行等應用的安全性要求。

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

3、SSL技術優點與不足

優點：

1) 提供較高的安全性保證

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

2) 支持各種應用層協議。

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

3) 部署簡單。

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

SSL協議的不足：

1）SSL要求對每個數據進行加密和解密操作，因而在帶來高性能的同時，對系統也要求高資源開銷。

2）SSL協議主要是使用公開密鑰體制和X.509數字證書技術保護信息傳輸的機密性和完整性，它不能保證信息的不可抵賴性，主要適用於點對點之間的信息傳輸，常用Web Server方式。 3）SSL為帶有安全功能的TCP/IP套接字應用程序接口提供了一個替代的方法，理論上，在SSL之上可以安全方式運行任何原有TCP/IP應用程序而不需修改，但實際上，SSL目前還只是用在HTTP連接上。

二、SSL協議的工作原理

1、SSL協議所處的位置

SSL介於應用層和TCP層之間。應用層數據不再直接傳遞給傳輸層，而是傳

遞給SSL層，SSL層對從應用層收到的數據進行加密，並增加自己的SSL頭。

如上圖所示，SSL位於應用層和傳輸層之間，它可以為任何基於TCP等可靠連接的應用層協議提供安全性保證。SSL協議本身分為兩層：

上層為SSL握手協議（SSL handshake protocol）、SSL密碼變化協議（SSL change cipher spec protocol）和SSL警告協議（SSL alert protocol）

底層為SSL記錄協議（SSL record protocol）。

其中：

SSL握手協議：是SSL協議非常重要的組成部分，用來協商通信過程中使用的加密套件（加密算法、密鑰交換算法和MAC算法等）、在服務器和客戶端之間安全地交換密鑰、實現服務器和客戶端的身份驗證。

SSL密碼變化協議：客戶端和服務器端通過密碼變化協議通知對端，隨後的報文都將使用新協商的加密套件和密鑰進行保護和傳輸。

SSL警告協議：用來向通信對端報告告警信息，消息中包含告警的嚴重級別和描述。

SSL記錄協議：主要負責對上層的數據（SSL握手協議、SSL密碼變化協議、SSL警告協議和應用層協議報文）進行分塊、計算並添加MAC值、加密，並把處理後的記錄塊傳輸給對端。

2、協議安全機制

1) 傳輸數據的機密性

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

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

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

2) 身份驗證機制

電子商務和網上銀行等應用中必須保證要登錄的Web服務器是真實的，以免重要信息被非法竊取。SSL利用數字簽名來驗證通信對端的身份。

非對稱密鑰算法可以用來實現數字簽名。由於通過私鑰加密後的數據只能利用對應的公鑰進行解密，因此根據解密是否成功，就可以判斷髮送者的身份，如同發送者對數據進行了"簽名"。

SSL客戶端必須驗證SSL服務器的身份，SSL服務器是否驗證SSL客戶端的身份，則由SSL服務器決定。

使用數字簽名驗證身份時，需要確保被驗證者的公鑰是真實的，否則，非法用戶可能會冒充被驗證者與驗證者通信。如下圖所示，Cindy冒充Bob，將自己的公鑰發給Alice，並利用自己的私鑰計算出簽名發送給Alice，Alice利用"Bob"的公鑰（實際上為Cindy的公鑰）成功驗證該簽名，則Alice認為Bob的身份驗證成功，而實際上與Alice通信的是冒充Bob的Cindy。SSL利用PKI提供的機制保證公鑰的真實性。PKI技術在我之前的文章裡有詳細闡述。

3) 消息完整性驗證

為了避免網絡中傳輸的數據被非法篡改，SSL利用基於MD5或SHA的MAC算法來保證消息的完整性。

MAC算法是在密鑰參與下的數據摘要算法，能將密鑰和隨意長度的數據轉換為固定長度的數據。利用MAC算法驗證消息完整性的過程如下圖所看到的。

發送者在密鑰的參與下，利用MAC算法計算出消息的MAC值。並將其加在消息之後發送給接收者。接收者利用相同的密鑰和MAC算法計算出消息的MAC值。並與接收到的MAC值比較。假設二者相同。則報文沒有改變；否則，報文在傳輸過程中被改動，接收者將丟棄該報文。

MAC算法具有如以下特徵，使其可以用來驗證消息的完整性：

消息的不論什麼改變，都會引起輸出的固定長度數據產生變化。通過比較MAC值，可以保證接收者可以發現消息的改變。

MAC算法須要密鑰的參與。因此沒有密鑰的非法用戶在改變消息的內容後，無法加入正確的MAC值。從而保證非法用戶無法任意改動消息內容。

3、SSL協議握手過程

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

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

1) 只驗證服務器的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服務器的身份驗證。

2) 驗證服務器和客戶端的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) 恢復原有會話的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、利用抓包工具直觀分析SSL握手連接過程

下面從抓包數據來具體分析這一過程並說明各部分數據的作用以及如實現前面列出的握手的目標，當然了，最重要的還是說明為何這一過程是安全可靠的，第三方無法截獲，篡改或者假冒。

SSL一次請求與響應整體流程圖：

1) client發送ClientHello

每一條消息都會包含有ContentType,Version,HandshakeType等信息。

2) server迴應ServerHello

這裡多了個session id,如果SSL連接斷開，再次連接時，可以使用該屬性重新建立連接，在雙方都有緩存的情況下可以省略握手的步驟。

server端也會生成隨機的RN，用於生成session key使用。

server會從client發送的Cipher suite列表中跳出一個，這裡挑選的是RSA+RC4+MD5

這次server共發送的3個handshake 消息:Serverhello，Certificate和ServerHelloDone，共用一個ContentType:Handshake

3) server發送Certificate

server的證書信息，只包含public key，server將該public key對應的private key保存好，用於證明server是該證書的實際擁有者，那麼如何驗證呢？原理很簡單：client隨機生成一串數，用server這裡的public key加密(顯然是RSA算法)，發給server，server用private key解密後返回給client，client與原文比較，如果一致，則說明server擁有private key，也就說明與client通信的正是證書的擁有者，因為public key加密的數據，只有private key才能解密，目前的技術還沒發破解。利用這個原理，也能實現session key的交換，加密前的那串隨機數就可用作session key，因為除了client和server，沒有第三方能獲得該數據了。原理很簡單，實際使用時會複雜很多，數據經過多次hash，偽隨機等的運算，前面提到的client和server端得RN都會參與計算。

4) Server發送ServerHelloDone

5) Client發送ClientKeyExchange

client拿到server的certificate後，就可以開始利用certificate裡的public key進行session key的交換了。從圖中可以看出，client發送的是130字節的字節流，顯然是加過密的。client隨機生成48字節的Pre-mastersecret，padding後用public key加密就得到這130字節的數據發送給server，server解密也能得到Pre-mastersecret。雙方使用pre-master secret, "mastersecret"常量字節流，前期交換的server端RN和client的RN作為參數，使用一個偽隨機函數PRF，其實就是hash之後再hash，最後得到48字節的master secret。master secret再與"key expansion"常量，雙方RN經過偽隨機函數運算得到key_block，PRF偽隨機函數可以可以彷彿循環輸出數據，因此我們想得到多少字節都可以，就如Random偽隨機函數，給它一個種子，後續用hash計算能得到無數個隨機數，如果每次種子相同，得到的序列是一樣的，但是這裡的輸入時48字節的master secret，2個28字節的RN和一個字符串常量，碰撞的可能性是很小的。得到key block後，算法，就從中取出session key，IV(對稱算法中使用的初始化向量)等。client和server使用的session key是不一樣的，但只要雙方都知道對方使用的是什麼就行了。這裡會取出4個：client/server加密正文的key，client/server計算handshake數據hash的key。

6) Client發送ChangeCipherSpec

client指示Server從現在開始發送的消息都是加密過的。

7) 7.Client發送Finished

client發送的加密數據，這個消息非常關鍵，一是能證明握手數據沒有被篡改過，二也能證明自己確實是密鑰的擁有者(這裡是單邊驗證，只有server有certificate，server發送的Finished能證明自己含有private key，原理是一樣的)。client將之前發送的所有握手消息存入handshakemessages緩存，進行MD5和SHA-1兩種hash運算，再與前面的master secret和一串常量"client finished"進行PRF偽隨機運算得到12字節的verify data，還要經過改進的MD5計算得到加密信息。為什麼能證明上述兩點呢，前面說了只有密鑰的擁有者才能解密得到pre-master key，master key，最後得到key block後，進行hash運算得到的結果才與發送方的一致。

8) Server發送ChangeCipherSpec

Server指示client從現在開始發送的消息都是加密過的。

9) Server發送Finishd

與client發送Finished計算方法一致。server發送的Finished裡包含hash給client，client會進行校驗，如果通過，說明握手過程中的數據沒有被第三方篡改過，也說明server是之前交換證書的擁有者。現在雙方就可以開始後續通信，進入Application context了。

三、SSL的應用場景

SSL協議主要應用於"HTTPS"和"SSL VPN"兩大場景。

HTTPS通過SSL提供的數據加密、身份驗證和消息完整性驗證等安全機制，為Web訪問提供了安全性保證。

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

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

四、SSL有弱點嗎？能否被"黑客"攻破？

安全套接層(SSL)被用於保護無數的網絡用戶，但是它有什麼弱點呢?最近幾年出現了許多專門攻擊SSL的攻擊。雖然這個技術實際上還是比較安全的，但是攻擊者一直在尋找漏洞繞過安全協議和標準。其中SSL是他們的主要目標。SSL被用於保護敏感的超文本傳輸協議(HTTP)流量。有一些攻擊者則不這樣想，他們一直在尋找訪問敏感數據的新方法。

下面主要介紹常見"SSL"攻擊方法：

1、欺騙手段

欺騙用戶接入一個錯誤的證書。這是一種攻擊SSL用戶的常用方法。其方法是讓用戶不顧看到的警告或錯誤，仍然堅持訪問這個網站。雖然發起這種攻擊很簡單，但是它要求受攻擊者接受一個明顯有問題的證書。大多數用戶都會發現這種欺騙行為;因此，這種威脅的級別較低。

2、虛假證書

雖然這種方法聽起來有一些牽強，但是它曾經取得成功。有時攻擊者能夠獲得一個有效的證書，然後用它們執行惡意行為。例如，在2011年，有攻擊者攻破了荷蘭證書授權的安全機制，然後偽造了雅虎、谷歌、Wordpress等網站的證書。在獲得有效的證書之後，這些攻擊者繞過了HTTPS保護。但是，這種攻擊的整體級別仍然比較低。

3、移除SSL，直接通過明文發送數據

2009年出現了一種新的SSL攻擊方法，它來自於SSLStrip。這個工具不會讓用戶看到警告信息，而是充當一個代理服務器的作用，去掉了HTTPS的S(安全性)，這樣用戶就只能通過HTTP直接訪問。SSLStrip還允許攻擊者給用戶看到加鎖網站圖標，所以發現錯誤的唯一方法就是瀏覽器地址欄只顯示HTTP，而不是HTTPS。如果用戶沒有注意到這個細微差別，那麼攻擊者就可以訪問到受保護的數據。這種攻擊的威脅級別屬於中級。

4、破解密鑰

目前大多數證書都使用1024位或2048位密鑰。2048位密鑰非常可靠，想要使用一臺普通桌面電腦來暴力破解它，這幾乎是不可能的。即使如此，已經有報告指出，National Security Agency已經成功獲得了SSL流量的訪問。雖然有人認為NSA可能發現了新的量子計算技術，但是這個機構完全有可能直接獲得了加密密鑰或者在軟件和硬件中植入了後門(入口)。NSA及其他訪問安全數據的方法的威脅級別還不確定。

5、中間人攻擊

這種攻擊是一種主動竊聽形式，攻擊者將通過獨立連接訪問攻擊目標，然後向服務器發送信息。其中一個例子就是Lucky 13，它是用傳輸層安全媒體訪問控制計算的13位頭信息命名的。雖然這種密文攻擊在理論上是可能實現的，但是它要求先控制環境，而且需要很長的時間;所以，它的威脅級別非常低。

6、邊信道攻擊

過去幾年出現了幾次邊信道攻擊，它已經證明可用於恢復驗證所使用的HTTP請求和Cookies。 通過適應性超文本壓縮實現的瀏覽器偵測和洩漏(BREACH)就是一個例子。BREACH利用壓縮和HTPP響應，它們一般都使用gzip等機制壓縮。對於可能受到攻擊的應用，它必須使用HTTP級壓縮，在HTTP響應中加入用戶輸入，然後暴露HTTP響應體的跨站請求偽造令牌。雖然這在理論上是可行的，但是有一些方法可以抑制這種攻擊，因此它的威脅級別也較低。

7、Downgrade（降級攻擊）

降級攻擊是一種對計算機系統或者通信協議的攻擊，在降級攻擊中，攻擊者故意使系統放棄新式、安全性高的工作方式，反而使用為向下兼容而準備的老式、安全性差的工作方式，降級攻擊常被用於中間人攻擊，講加密的通信協議安全性大幅削弱，得以進行原本不可能做到的攻擊。 在現代的回退防禦中，使用單獨的信號套件來指示自願降級行為，需要理解該信號並支持更高協議版本的服務器來終止協商，該套件是TLS_FALLBACK_SCSV(0x5600)

8、CRIME（罪惡攻擊）

CRIME(CVE-2012-4929)，全稱Compression Ratio Info-leak Made Easy，這是一種因SSL壓縮造成的安全隱患，通過它可竊取啟用數據壓縮特性的HTTPS或SPDY協議傳輸的私密Web Cookie。在成功讀取身份驗證Cookie後，攻擊者可以實行會話劫持和發動進一步攻擊。

SSL 壓縮在下述版本是默認關閉的： nginx 1.1.6及更高/1.0.9及更高（如果使用了 OpenSSL 1.0.0及更高）， nginx 1.3.2及更高/1.2.2及更高（如果使用較舊版本的 OpenSSL）。

如果你使用一個早期版本的 nginx 或 OpenSSL，而且你的發行版沒有向後移植該選項，那麼你需要重新編譯沒有一個 ZLIB 支持的 OpenSSL。這會禁止 OpenSSL 使用 DEFLATE 壓縮方式。如果你禁用了這個，你仍然可以使用常規的 HTML DEFLATE 壓縮。

9、Heartbleed（心血漏洞）

Heartbleed(CVE-2014-0160) 是一個於2014年4月公佈的 OpenSSL 加密庫的漏洞，它是一個被廣泛使用的傳輸層安全（TLS）協議的實現。無論是服務器端還是客戶端在 TLS 中使用了有缺陷的 OpenSSL，都可以被利用該缺陷。由於它是因 DTLS 心跳擴展（RFC 6520）中的輸入驗證不正確（缺少了邊界檢查）而導致的，所以該漏洞根據"心跳"而命名。這個漏洞是一種緩存區超讀漏洞，它可以讀取到本不應該讀取的數據。如果使用帶缺陷的Openssl版本，無論是服務器還是客戶端，都可能因此受到攻擊。

10、POODLE漏洞（捲毛狗攻擊）

2014年10月14號由Google發現的POODLE漏洞，全稱是Padding Oracle On Downloaded Legacy Encryption vulnerability，又被稱為"貴賓犬攻擊"（CVE-2014-3566），POODLE漏洞只對CBC模式的明文進行了身份驗證，但是沒有對填充字節進行完整性驗證，攻擊者竊取採用SSL3.0版加密通信過程中的內容，對填充字節修改並且利用預置填充來恢復加密內容，以達到攻擊目的。

11、TLS POODLE（TLS捲毛狗攻擊）

TLS POODLE(CVE-2014-8730) 該漏洞的原理和POODLE漏洞的原理一致，但不是SSL3協議。由於TLS填充是SSLv3的一個子集，因此可以重新使用針對TLS的POODLE攻擊。TLS對於它的填充格式是非常嚴格的，但是一些TLS實現在解密之後不執行填充結構的檢查。即使使用TLS也不會容易受到POODLE攻擊的影響。

12、DROWN（溺水攻擊/溺亡攻擊）

2016年3月發現的針對TLS的新漏洞攻擊——DROWN（Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800），也即利用過時的、弱化的一種RSA加密算法來解密破解TLS協議中被該算法加密的會話密鑰。 具體說來，DROWN漏洞可以利用過時的SSLv2協議來解密與之共享相同RSA私鑰的TLS協議所保護的流量。 DROWN攻擊依賴於SSLv2協議的設計缺陷以及知名的Bleichenbacher攻擊。