ssl協(xié)議(ssl協(xié)議是什么)

"SSL"協(xié)議對(duì)于黑客技術(shù)學(xué)習(xí),是必須要掌握的,因?yàn)樗诤芏鄳?yīng)用通信中無(wú)處不在。

"SSL"這個(gè)名詞，可能大家沒怎么聽說(shuō)過，但是它的一個(gè)應(yīng)用大家肯定都熟悉，那就是"HTTPS"！

HTTPS是基于SSL安全連接的HTTP協(xié)議。HTTPS通過SSL提供的數(shù)據(jù)加密、身份驗(yàn)證和消息完整性驗(yàn)證等安全機(jī)制，為Web訪問提供了安全性保證，廣泛應(yīng)用于網(wǎng)上銀行、電子商務(wù)等領(lǐng)域。

"SSL"是不是很牛！今天我就給大家以本篇文章內(nèi)容詳細(xì)解析一下"SSL"安全協(xié)議！

1、基本定義

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

2、產(chǎn)生背景

基于因特網(wǎng)的電子商務(wù)和網(wǎng)上銀行等新興應(yīng)用，極大地方便了人們的日常生活，受到人們的青睞。由于這些應(yīng)用都需要在網(wǎng)絡(luò)上進(jìn)行在線交易，它們對(duì)網(wǎng)絡(luò)通 信的安全性提出了更高的要求。

傳統(tǒng)的因特網(wǎng)協(xié)議HTTP不具備安全機(jī)制——采用明文的形式傳輸數(shù)據(jù)、不能驗(yàn)證通信雙方的身份、無(wú)法防止傳輸?shù)臄?shù)據(jù)被篡改 等，導(dǎo)致HTTP無(wú)法滿足電子商務(wù)和網(wǎng)上銀行等應(yīng)用的安全性要求。

Netscape公司提出的安全協(xié)議SSL，利用數(shù)據(jù)加密、身份驗(yàn)證和消息完整性驗(yàn)證機(jī)制，為網(wǎng)絡(luò)上數(shù)據(jù)的傳輸提供安全性保證。SSL可以為HTTP提供安全連接，從而很大程度上改善了因特網(wǎng)的安全性問題

3、SSL技術(shù)優(yōu)點(diǎn)與不足

優(yōu)點(diǎn)：

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

SSL利用數(shù)據(jù)加密、身份驗(yàn)證和消息完整性驗(yàn)證機(jī)制，保證網(wǎng)絡(luò)上數(shù)據(jù)傳輸?shù)陌踩浴?/p>

2) 支持各種應(yīng)用層協(xié)議。

雖然SSL設(shè)計(jì)的初衷是為了解決萬(wàn)維網(wǎng)安全性問題，但是由于SSL位于應(yīng)用層和傳輸層之間，它可以為任何基于TCP等可靠連接的應(yīng)用層協(xié)議提供安全性保證。

3) 部署簡(jiǎn)單。

目前SSL已經(jīng)成為網(wǎng)絡(luò)中用來(lái)鑒別網(wǎng)站和網(wǎng)頁(yè)瀏覽者身份，在瀏覽器使用者及Web服務(wù)器之間進(jìn)行加密通信的全球化標(biāo)準(zhǔn)。SSL協(xié)議已被集成到大部分的瀏覽器中，如IE、Netscape、Firefox等。這就意味著幾乎任意一臺(tái)裝有瀏覽器的計(jì)算機(jī)都支持SSL連接，不需要安裝額外的客戶端軟件。

SSL協(xié)議的不足：

1）SSL要求對(duì)每個(gè)數(shù)據(jù)進(jìn)行加密和解密操作，因而在帶來(lái)高性能的同時(shí)，對(duì)系統(tǒng)也要求高資源開銷。

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

1、SSL協(xié)議所處的位置

SSL介于應(yīng)用層和TCP層之間。應(yīng)用層數(shù)據(jù)不再直接傳遞給傳輸層，而是傳

遞給SSL層，SSL層對(duì)從應(yīng)用層收到的數(shù)據(jù)進(jìn)行加密，并增加自己的SSL頭。

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

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

底層為SSL記錄協(xié)議（SSL record protocol）。

其中：

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

SSL密碼變化協(xié)議：客戶端和服務(wù)器端通過密碼變化協(xié)議通知對(duì)端，隨后的報(bào)文都將使用新協(xié)商的加密套件和密鑰進(jìn)行保護(hù)和傳輸。

SSL警告協(xié)議：用來(lái)向通信對(duì)端報(bào)告告警信息，消息中包含告警的嚴(yán)重級(jí)別和描述。

SSL記錄協(xié)議：主要負(fù)責(zé)對(duì)上層的數(shù)據(jù)（SSL握手協(xié)議、SSL密碼變化協(xié)議、SSL警告協(xié)議和應(yīng)用層協(xié)議報(bào)文）進(jìn)行分塊、計(jì)算并添加MAC值、加密，并把處理后的記錄塊傳輸給對(duì)端。

2、協(xié)議安全機(jī)制

1) 傳輸數(shù)據(jù)的機(jī)密性

網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)非常容易被非法用戶竊取，SSL采用在通信兩方之間建立加密通道的方法保證傳輸數(shù)據(jù)的機(jī)密性。

所謂加密通道，是指發(fā)送方在發(fā)送數(shù)據(jù)前，使用加密算法和加密密鑰對(duì)數(shù)據(jù)進(jìn)行加密，然后將數(shù)據(jù)發(fā)送給對(duì)方。接收方接收到數(shù)據(jù)后，利用解密算法和解密密鑰從密文中獲取明文。沒有解密密鑰的第三方，無(wú)法將密文恢復(fù)為明文，從而保 證傳輸數(shù)據(jù)的機(jī)密性。

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

2) 身份驗(yàn)證機(jī)制

電子商務(wù)和網(wǎng)上銀行等應(yīng)用中必須保證要登錄的Web服務(wù)器是真實(shí)的，以免重要信息被非法竊取。SSL利用數(shù)字簽名來(lái)驗(yàn)證通信對(duì)端的身份。

非對(duì)稱密鑰算法可以用來(lái)實(shí)現(xiàn)數(shù)字簽名。由于通過私鑰加密后的數(shù)據(jù)只能利用對(duì)應(yīng)的公鑰進(jìn)行解密，因此根據(jù)解密是否成功，就可以判斷發(fā)送者的身份，如同發(fā)送者對(duì)數(shù)據(jù)進(jìn)行了"簽名"。

SSL客戶端必須驗(yàn)證SSL服務(wù)器的身份，SSL服務(wù)器是否驗(yàn)證SSL客戶端的身份，則由SSL服務(wù)器決定。

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

3) 消息完整性驗(yàn)證

為了避免網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)被非法篡改，SSL利用基于MD5或SHA的MAC算法來(lái)保證消息的完整性。

MAC算法是在密鑰參與下的數(shù)據(jù)摘要算法，能將密鑰和隨意長(zhǎng)度的數(shù)據(jù)轉(zhuǎn)換為固定長(zhǎng)度的數(shù)據(jù)。利用MAC算法驗(yàn)證消息完整性的過程如下圖所看到的。

發(fā)送者在密鑰的參與下，利用MAC算法計(jì)算出消息的MAC值。并將其加在消息之后發(fā)送給接收者。接收者利用相同的密鑰和MAC算法計(jì)算出消息的MAC值。并與接收到的MAC值比較。假設(shè)二者相同。則報(bào)文沒有改變；否則，報(bào)文在傳輸過程中被改動(dòng)，接收者將丟棄該報(bào)文。

MAC算法具有如以下特征，使其可以用來(lái)驗(yàn)證消息的完整性：

消息的不論什么改變，都會(huì)引起輸出的固定長(zhǎng)度數(shù)據(jù)產(chǎn)生變化。通過比較MAC值，可以保證接收者可以發(fā)現(xiàn)消息的改變。

MAC算法須要密鑰的參與。因此沒有密鑰的非法用戶在改變消息的內(nèi)容后，無(wú)法加入正確的MAC值。從而保證非法用戶無(wú)法任意改動(dòng)消息內(nèi)容。

3、SSL協(xié)議握手過程

SSL通過握手過程在客戶端和服務(wù)器之間協(xié)商會(huì)話參數(shù)，并建立會(huì)話。會(huì)話包含的主要參數(shù)有會(huì)話ID、對(duì)方的證書、加密套件（密鑰交換算法、數(shù)據(jù)加密算法和MAC算法等）以及主密鑰（master cret）。通過SSL會(huì)話傳輸?shù)臄?shù)據(jù)，都將采用該會(huì)話的主密鑰和加密套件進(jìn)行加密、計(jì)算MAC等處理。

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

1) 只驗(yàn)證服務(wù)器的SSL握手過程

過程如下：

(1) SSL客戶端通過Client Hello消息將它支持的SSL版本、加密算法、密鑰交換算法、MAC算法等信息發(fā)送給SSL服務(wù)器。

(2) SSL服務(wù)器確定本次通信采用的SSL版本和加密套件，并通過Server Hello消息通知給SSL客戶端。如果SSL服務(wù)器允許SSL客戶端在以后的通信中重用本次會(huì)話，則SSL服務(wù)器會(huì)為本次會(huì)話分配會(huì)話ID，并通過Server Hello消息發(fā)送給SSL客戶端。

(3) SSL服務(wù)器將攜帶自己公鑰信息的數(shù)字證書通過Certificate消息發(fā)送給SSL客戶端。

(4) SSL服務(wù)器發(fā)送Server Hello Done消息，通知SSL客戶端版本和加密套件協(xié)商結(jié)束，開始進(jìn)行密鑰交換。

(5) SSL客戶端驗(yàn)證SSL服務(wù)器的證書合法后，利用證書中的公鑰加密SSL客戶端隨機(jī)生成的premaster cret，并通過Client Key Exchange消息發(fā)送給SSL服務(wù)器。

(6) SSL客戶端發(fā)送Change Cipher Spec消息，通知SSL服務(wù)器后續(xù)報(bào)文將采用協(xié)商好的密鑰和加密套件進(jìn)行加密和MAC計(jì)算。

(7) SSL客戶端計(jì)算已交互的握手消息（除Change Cipher Spec消息外所有已交互的消息）的Hash值，利用協(xié)商好的密鑰和加密套件處理Hash值（計(jì)算并添加MAC值、加密等），并通過Finished消息發(fā)送給SSL服務(wù)器。SSL服務(wù)器利用同樣的方法計(jì)算已交互的握手消息的Hash值，并與Finished消息的解密結(jié)果比較，如果二者相同，且MAC值驗(yàn)證成功，則證明密鑰和加密套件協(xié)商成功。

(8) 同樣地，SSL服務(wù)器發(fā)送Change Cipher Spec消息，通知SSL客戶端后續(xù)報(bào)文將采用協(xié)商好的密鑰和加密套件進(jìn)行加密和MAC計(jì)算。

(9) SSL服務(wù)器計(jì)算已交互的握手消息的Hash值，利用協(xié)商好的密鑰和加密套件處理Hash值（計(jì)算并添加MAC值、加密等），并通過Finished消息發(fā)送給SSL客戶端。SSL客戶端利用同樣的方法計(jì)算已交互的握手消息的Hash值，并與Finished消息的解密結(jié)果比較，如果二者相同，且MAC值驗(yàn)證成功，則證明密鑰和加密套件協(xié)商成功。

SSL客戶端接收到SSL服務(wù)器發(fā)送的Finished消息后，如果解密成功，則可以判斷SSL服務(wù)器是數(shù)字證書的擁有者，即SSL服務(wù)器身份驗(yàn)證成功，因?yàn)橹挥袚碛兴借€的SSL服務(wù)器才能從Client Key Exchange消息中解密得到premaster cret，從而間接地實(shí)現(xiàn)了SSL客戶端對(duì)SSL服務(wù)器的身份驗(yàn)證。

2) 驗(yàn)證服務(wù)器和客戶端的SSL握手過程

過程如下：

(1) SSL服務(wù)器發(fā)送Certificate Request消息，請(qǐng)求SSL客戶端將其證書發(fā)送給SSL服務(wù)器。

(2) SSL客戶端通過Certificate消息將攜帶自己公鑰的證書發(fā)送給SSL服務(wù)器。SSL服務(wù)器驗(yàn)證該證書的合法性。

(3) SSL客戶端計(jì)算已交互的握手消息、主密鑰的Hash值，利用自己的私鑰對(duì)其進(jìn)行加密，并通過Certificate Verify消息發(fā)送給SSL服務(wù)器。

(4) SSL服務(wù)器計(jì)算已交互的握手消息、主密鑰的Hash值，利用SSL客戶端證書中的公鑰解密Certificate Verify消息，并將解密結(jié)果與計(jì)算出的Hash值比較。如果二者相同，則SSL客戶端身份驗(yàn)證成功。

3) 恢復(fù)原有會(huì)話的SSL握手過程

(1) SSL客戶端發(fā)送Client Hello消息，消息中的會(huì)話ID設(shè)置為計(jì)劃重用的會(huì)話的ID。

(2) SSL服務(wù)器如果允許重用該會(huì)話，則通過在Server Hello消息中設(shè)置相同的會(huì)話ID來(lái)應(yīng)答。這樣，SSL客戶端和SSL服務(wù)器就可以利用原有會(huì)話的密鑰和加密套件，不必重新協(xié)商。

(3) SSL客戶端發(fā)送Change Cipher Spec消息，通知SSL服務(wù)器后續(xù)報(bào)文將采用原有會(huì)話的密鑰和加密套件進(jìn)行加密和MAC計(jì)算。

(4) SSL客戶端計(jì)算已交互的握手消息的Hash值，利用原有會(huì)話的密鑰和加密套件處理Hash值，并通過Finished消息發(fā)送給SSL服務(wù)器，以便SSL服務(wù)器判斷密鑰和加密套件是否正確。

(5) 同樣地，SSL服務(wù)器發(fā)送Change Cipher Spec消息，通知SSL客戶端后續(xù)報(bào)文將采用原有會(huì)話的密鑰和加密套件進(jìn)行加密和MAC計(jì)算。

(6) SSL服務(wù)器計(jì)算已交互的握手消息的Hash值，利用原有會(huì)話的密鑰和加密套件處理Hash值，并通過Finished消息發(fā)送給SSL客戶端，以便SSL客戶端判斷密鑰和加密套件是否正確

4、利用抓包工具直觀分析SSL握手連接過程

下面從抓包數(shù)據(jù)來(lái)具體分析這一過程并說(shuō)明各部分?jǐn)?shù)據(jù)的作用以及如實(shí)現(xiàn)前面列出的握手的目標(biāo)，當(dāng)然了，最重要的還是說(shuō)明為何這一過程是安全可靠的，第三方無(wú)法截獲，篡改或者假冒。

SSL一次請(qǐng)求與響應(yīng)整體流程圖：

1) client發(fā)送ClientHello

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

2) rver回應(yīng)ServerHello

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

rver端也會(huì)生成隨機(jī)的RN，用于生成ssion key使用。

rver會(huì)從client發(fā)送的Cipher suite列表中跳出一個(gè)，這里挑選的是RSA+RC4+MD5

這次rver共發(fā)送的3個(gè)handshake 消息:Serverhello，Certificate和ServerHelloDone，共用一個(gè)ContentType:Handshake

3) rver發(fā)送Certificate

rver的證書信息，只包含public key，rver將該public key對(duì)應(yīng)的private key保存好，用于證明rver是該證書的實(shí)際擁有者，那么如何驗(yàn)證呢？原理很簡(jiǎn)單：client隨機(jī)生成一串?dāng)?shù)，用rver這里的public key加密(顯然是RSA算法)，發(fā)給rver，rver用private key解密后返回給client，client與原文比較，如果一致，則說(shuō)明rver擁有private key，也就說(shuō)明與client通信的正是證書的擁有者，因?yàn)閜ublic key加密的數(shù)據(jù)，只有private key才能解密，目前的技術(shù)還沒發(fā)破解。利用這個(gè)原理，也能實(shí)現(xiàn)ssion key的交換，加密前的那串隨機(jī)數(shù)就可用作ssion key，因?yàn)槌薱lient和rver，沒有第三方能獲得該數(shù)據(jù)了。原理很簡(jiǎn)單，實(shí)際使用時(shí)會(huì)復(fù)雜很多，數(shù)據(jù)經(jīng)過多次hash，偽隨機(jī)等的運(yùn)算，前面提到的client和rver端得RN都會(huì)參與計(jì)算。

4) Server發(fā)送ServerHelloDone

5) Client發(fā)送ClientKeyExchange

client拿到rver的certificate后，就可以開始利用certificate里的public key進(jìn)行ssion key的交換了。從圖中可以看出，client發(fā)送的是130字節(jié)的字節(jié)流，顯然是加過密的。client隨機(jī)生成48字節(jié)的Pre-mastercret，padding后用public key加密就得到這130字節(jié)的數(shù)據(jù)發(fā)送給rver，rver解密也能得到Pre-mastercret。雙方使用pre-master cret, "mastercret"常量字節(jié)流，前期交換的rver端RN和client的RN作為參數(shù)，使用一個(gè)偽隨機(jī)函數(shù)PRF，其實(shí)就是hash之后再hash，最后得到48字節(jié)的master cret。master cret再與"key expansion"常量，雙方RN經(jīng)過偽隨機(jī)函數(shù)運(yùn)算得到key_block，PRF偽隨機(jī)函數(shù)可以可以仿佛循環(huán)輸出數(shù)據(jù)，因此我們想得到多少字節(jié)都可以，就如Random偽隨機(jī)函數(shù)，給它一個(gè)種子，后續(xù)用hash計(jì)算能得到無(wú)數(shù)個(gè)隨機(jī)數(shù)，如果每次種子相同，得到的序列是一樣的，但是這里的輸入時(shí)48字節(jié)的master cret，2個(gè)28字節(jié)的RN和一個(gè)字符串常量，碰撞的可能性是很小的。得到key block后，算法，就從中取出ssion key，IV(對(duì)稱算法中使用的初始化向量)等。client和rver使用的ssion key是不一樣的，但只要雙方都知道對(duì)方使用的是什么就行了。這里會(huì)取出4個(gè)：client/rver加密正文的key，client/rver計(jì)算handshake數(shù)據(jù)hash的key。

6) Client發(fā)送ChangeCipherSpec

client指示Server從現(xiàn)在開始發(fā)送的消息都是加密過的。

7) 7.Client發(fā)送Finished

client發(fā)送的加密數(shù)據(jù)，這個(gè)消息非常關(guān)鍵，一是能證明握手?jǐn)?shù)據(jù)沒有被篡改過，二也能證明自己確實(shí)是密鑰的擁有者(這里是單邊驗(yàn)證，只有rver有certificate，rver發(fā)送的Finished能證明自己含有private key，原理是一樣的)。client將之前發(fā)送的所有握手消息存入handshakemessages緩存，進(jìn)行MD5和SHA-1兩種hash運(yùn)算，再與前面的master cret和一串常量"client finished"進(jìn)行PRF偽隨機(jī)運(yùn)算得到12字節(jié)的verify data，還要經(jīng)過改進(jìn)的MD5計(jì)算得到加密信息。為什么能證明上述兩點(diǎn)呢，前面說(shuō)了只有密鑰的擁有者才能解密得到pre-master key，master key，最后得到key block后，進(jìn)行hash運(yùn)算得到的結(jié)果才與發(fā)送方的一致。

8) Server發(fā)送ChangeCipherSpec

Server指示client從現(xiàn)在開始發(fā)送的消息都是加密過的。

9) Server發(fā)送Finishd

與client發(fā)送Finished計(jì)算方法一致。rver發(fā)送的Finished里包含hash給client，client會(huì)進(jìn)行校驗(yàn)，如果通過，說(shuō)明握手過程中的數(shù)據(jù)沒有被第三方篡改過，也說(shuō)明rver是之前交換證書的擁有者。現(xiàn)在雙方就可以開始后續(xù)通信，進(jìn)入Application context了。

SSL協(xié)議主要應(yīng)用于"HTTPS"和"SSL VPN"兩大場(chǎng)景。

HTTPS通過SSL提供的數(shù)據(jù)加密、身份驗(yàn)證和消息完整性驗(yàn)證等安全機(jī)制，為Web訪問提供了安全性保證。

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

SSL VPN是以SSL為基礎(chǔ)的VPN技術(shù)，利用SSL提供的安全機(jī)制，為用戶遠(yuǎn)程訪問公司內(nèi)部網(wǎng)絡(luò)提供了安全保證。SSL VPN通過在遠(yuǎn)程接入用戶和SSL VPN網(wǎng)關(guān)之間建立SSL安全連接，允許用戶通過各種Web瀏覽器，各種網(wǎng)絡(luò)接入方式，在任何地方遠(yuǎn)程訪問企業(yè)網(wǎng)絡(luò)資源，并能夠保證企業(yè)網(wǎng)絡(luò)的安全，保護(hù)企業(yè)內(nèi)部信息不被竊取。

安全套接層(SSL)被用于保護(hù)無(wú)數(shù)的網(wǎng)絡(luò)用戶，但是它有什么弱點(diǎn)呢?最近幾年出現(xiàn)了許多專門攻擊SSL的攻擊。雖然這個(gè)技術(shù)實(shí)際上還是比較安全的，但是攻擊者一直在尋找漏洞繞過安全協(xié)議和標(biāo)準(zhǔn)。其中SSL是他們的主要目標(biāo)。SSL被用于保護(hù)敏感的超文本傳輸協(xié)議(HTTP)流量。有一些攻擊者則不這樣想，他們一直在尋找訪問敏感數(shù)據(jù)的新方法。

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

1、欺騙手段

欺騙用戶接入一個(gè)錯(cuò)誤的證書。這是一種攻擊SSL用戶的常用方法。其方法是讓用戶不顧看到的警告或錯(cuò)誤，仍然堅(jiān)持訪問這個(gè)網(wǎng)站。雖然發(fā)起這種攻擊很簡(jiǎn)單，但是它要求受攻擊者接受一個(gè)明顯有問題的證書。大多數(shù)用戶都會(huì)發(fā)現(xiàn)這種欺騙行為;因此，這種威脅的級(jí)別較低。

2、虛假證書

雖然這種方法聽起來(lái)有一些牽強(qiáng)，但是它曾經(jīng)取得成功。有時(shí)攻擊者能夠獲得一個(gè)有效的證書，然后用它們執(zhí)行惡意行為。例如，在2011年，有攻擊者攻破了荷蘭證書授權(quán)的安全機(jī)制，然后偽造了雅虎、谷歌、Wordpress等網(wǎng)站的證書。在獲得有效的證書之后，這些攻擊者繞過了HTTPS保護(hù)。但是，這種攻擊的整體級(jí)別仍然比較低。

3、移除SSL，直接通過明文發(fā)送數(shù)據(jù)

2009年出現(xiàn)了一種新的SSL攻擊方法，它來(lái)自于SSLStrip。這個(gè)工具不會(huì)讓用戶看到警告信息，而是充當(dāng)一個(gè)代理服務(wù)器的作用，去掉了HTTPS的S(安全性)，這樣用戶就只能通過HTTP直接訪問。SSLStrip還允許攻擊者給用戶看到加鎖網(wǎng)站圖標(biāo)，所以發(fā)現(xiàn)錯(cuò)誤的唯一方法就是瀏覽器地址欄只顯示HTTP，而不是HTTPS。如果用戶沒有注意到這個(gè)細(xì)微差別，那么攻擊者就可以訪問到受保護(hù)的數(shù)據(jù)。這種攻擊的威脅級(jí)別屬于中級(jí)。

4、破解密鑰

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

5、中間人攻擊

這種攻擊是一種主動(dòng)竊聽形式，攻擊者將通過獨(dú)立連接訪問攻擊目標(biāo)，然后向服務(wù)器發(fā)送信息。其中一個(gè)例子就是Lucky 13，它是用傳輸層安全媒體訪問控制計(jì)算的13位頭信息命名的。雖然這種密文攻擊在理論上是可能實(shí)現(xiàn)的，但是它要求先控制環(huán)境，而且需要很長(zhǎng)的時(shí)間;所以，它的威脅級(jí)別非常低。

6、邊信道攻擊

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

7、Downgrade（降級(jí)攻擊）

降級(jí)攻擊是一種對(duì)計(jì)算機(jī)系統(tǒng)或者通信協(xié)議的攻擊，在降級(jí)攻擊中，攻擊者故意使系統(tǒng)放棄新式、安全性高的工作方式，反而使用為向下兼容而準(zhǔn)備的老式、安全性差的工作方式，降級(jí)攻擊常被用于中間人攻擊，講加密的通信協(xié)議安全性大幅削弱，得以進(jìn)行原本不可能做到的攻擊。 在現(xiàn)代的回退防御中，使用單獨(dú)的信號(hào)套件來(lái)指示自愿降級(jí)行為，需要理解該信號(hào)并支持更高協(xié)議版本的服務(wù)器來(lái)終止協(xié)商，該套件是TLS_FALLBACK_SCSV(0x5600)

8、CRIME（罪惡攻擊）

CRIME(CVE-2012-4929)，全稱Compression Ratio Info-leak Made Easy，這是一種因SSL壓縮造成的安全隱患，通過它可竊取啟用數(shù)據(jù)壓縮特性的HTTPS或SPDY協(xié)議傳輸?shù)乃矫躓eb Cookie。在成功讀取身份驗(yàn)證Cookie后，攻擊者可以實(shí)行會(huì)話劫持和發(fā)動(dòng)進(jìn)一步攻擊。

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

如果你使用一個(gè)早期版本的 nginx 或 OpenSSL，而且你的發(fā)行版沒有向后移植該選項(xiàng)，那么你需要重新編譯沒有一個(gè) ZLIB 支持的 OpenSSL。這會(huì)禁止 OpenSSL 使用 DEFLATE 壓縮方式。如果你禁用了這個(gè)，你仍然可以使用常規(guī)的 HTML DEFLATE 壓縮。

9、Heartbleed（心血漏洞）

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

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

2014年10月14號(hào)由Google發(fā)現(xiàn)的POODLE漏洞，全稱是Padding Oracle On Downloaded Legacy Encryption vulnerability，又被稱為"貴賓犬攻擊"（CVE-2014-3566），POODLE漏洞只對(duì)CBC模式的明文進(jìn)行了身份驗(yàn)證，但是沒有對(duì)填充字節(jié)進(jìn)行完整性驗(yàn)證，攻擊者竊取采用SSL3.0版加密通信過程中的內(nèi)容，對(duì)填充字節(jié)修改并且利用預(yù)置填充來(lái)恢復(fù)加密內(nèi)容，以達(dá)到攻擊目的。

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

TLS POODLE(CVE-2014-8730) 該漏洞的原理和POODLE漏洞的原理一致，但不是SSL3協(xié)議。由于TLS填充是SSLv3的一個(gè)子集，因此可以重新使用針對(duì)TLS的POODLE攻擊。TLS對(duì)于它的填充格式是非常嚴(yán)格的，但是一些TLS實(shí)現(xiàn)在解密之后不執(zhí)行填充結(jié)構(gòu)的檢查。即使使用TLS也不會(huì)容易受到POODLE攻擊的影響。

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

2016年3月發(fā)現(xiàn)的針對(duì)TLS的新漏洞攻擊——DROWN（Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800），也即利用過時(shí)的、弱化的一種RSA加密算法來(lái)解密破解TLS協(xié)議中被該算法加密的會(huì)話密鑰。 具體說(shuō)來(lái)，DROWN漏洞可以利用過時(shí)的SSLv2協(xié)議來(lái)解密與之共享相同RSA私鑰的TLS協(xié)議所保護(hù)的流量。 DROWN攻擊依賴于SSLv2協(xié)議的設(shè)計(jì)缺陷以及知名的Bleichenbacher攻擊。