針對2種SSL協(xié)議攻擊方法的解決方案

吳國鳳， 王芳芳， 張 巖

（1.合肥工業(yè)大學(xué) 計(jì)算機(jī)與信息學(xué)院，安徽 合肥 230009；2.安徽高新學(xué)院 計(jì)算機(jī)系，安徽 合肥 230001）

SSL協(xié)議［1］是由Netscape公司于1994年開發(fā)公布的，是一個(gè)保證數(shù)據(jù)安全傳輸?shù)陌踩珔f(xié)議，保證使用TCP／IP協(xié)議的通信應(yīng)用程序間的隱秘性和完整性。隨著信息技術(shù)的發(fā)展，日常生活中的諸多活動(dòng)都轉(zhuǎn)移到網(wǎng)絡(luò)上進(jìn)行，例如電子商務(wù)、網(wǎng)上銀行等，涉及密碼的保護(hù)、信息的篡改等安全問題［2］。SSL協(xié)議在客戶端與服務(wù)器端建立一條安全通道。不僅保證了信息的安全傳輸，又用對稱加密算法取代非對稱加密算法，提高了傳輸效率，還進(jìn)行了服務(wù)器端與客戶端的相互身份認(rèn)證。

然而SSL協(xié)議在應(yīng)用中還是遇到很多安全問題。本文主要介紹SSL Sniffing攻擊和SSL Stripping攻擊，對這2種基于中間人攻擊的方法做出詳細(xì)分析，同時(shí)提出了解決方案。

1 SSL協(xié)議

SSL協(xié)議主要分為2層，分別為SSL握手協(xié)議和SSL記錄協(xié)議。

1.1 SSL握手協(xié)議

SSL握手協(xié)議是在實(shí)際數(shù)據(jù)傳輸之前的必要步驟，進(jìn)行通信雙方的身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。工作過程的具體描述如下（以下客戶端標(biāo)識(shí)為Client，服務(wù)器端標(biāo)識(shí)為Server）。

（1）Client發(fā)起連接請求。Client向Server發(fā)送ClientHello消息發(fā)起SSL握手請求，發(fā)送的消息中包含客戶端所支持的加密算法、壓縮方法以及用于生成主密鑰的隨機(jī)數(shù)ClientRandom。

（2）Server響應(yīng)Client的ClientHello消息，發(fā)送一個(gè)ServerHello消息。消息中包含所選擇的加密算法、壓縮算法以及另外一個(gè)用于生成主密鑰的隨機(jī)數(shù)ServerRandom。同時(shí)Server向Client發(fā)送自己所持有的可信第三方頒發(fā)的證書，用于驗(yàn)證服務(wù)器的身份。

（3）Client對接收到的證書進(jìn)行可靠性驗(yàn)證，包括頒發(fā)機(jī)構(gòu)、有效日期等，若確定為可信，則繼續(xù)握手，否則放棄握手。

（4）Client與Server分別向?qū)Ψ桨l(fā)送KeyExchange消息，交換預(yù)主密鑰。

（5）Server向Client發(fā)送Finished消息，表示握手消息全部完成。

上述握手消息的第4步之后，若Server請求對Client進(jìn)行身份認(rèn)證，則Client也必須向Server發(fā)送所持有的可信第三方頒發(fā)的證書。

1.2 SSL記錄協(xié)議

記錄協(xié)議建立在TCP／IP協(xié)議之上，為數(shù)據(jù)傳輸提供數(shù)據(jù)加密和數(shù)據(jù)壓縮等功能。在握手協(xié)議中，雙方完成預(yù)主密鑰的交換之后，Client和Server分別利用隨機(jī)數(shù)值和預(yù)主密鑰獨(dú)立計(jì)算出對稱密鑰和MAC密鑰，用MAC算法保證數(shù)據(jù)的完整性，用握手協(xié)議中選擇的加密算法和計(jì)算出來的加密密鑰保證機(jī)密性。

1.3 Diffie－Hellman算法

Diffie－Hellman算法即 D－H 算法［3］，其安全性取決于離散對數(shù)的計(jì)算困難。算法主要用于密鑰的分發(fā)，而不是加密解密。在SSL協(xié)議中客戶端與服務(wù)器端同步一個(gè)會(huì)話密鑰。D－H密鑰協(xié)商過程如下。

（1）Client和Server共享大素?cái)?shù)p和g，其中g(shù)是p的原根。

（2）Client選擇一個(gè)隨機(jī)整數(shù)XC，計(jì)算YC＝g∧XCmod p，同時(shí)將YC發(fā)送給Server。

（3）Server選擇一個(gè)隨機(jī)整數(shù)XS，計(jì)算YS＝g∧XSmod p，同時(shí)將YS發(fā)送給Client。

（4）Client計(jì)算會(huì)話密鑰KC＝Y(jié)S∧XCmod p。

（5）Server計(jì)算會(huì)話密鑰KS＝Y(jié)C∧XSmod p。計(jì)算：

即KC＝KS。

其中，g和p公開；YC和YS在網(wǎng)絡(luò)中明文傳輸；XC為Client的密鑰；XS為Server的密鑰。由于離散對數(shù)的計(jì)算難度，在已知g、p、YC和YS的情況下，幾乎是不可能求出XC和XS，所以D－H算法在Client和Server之間安全地完成了密鑰交換［4］，計(jì)算出會(huì)話密鑰。

2 SSL安全攻擊

SSL協(xié)議保證數(shù)據(jù)的安全傳輸，但從SSL協(xié)議開始使用以來，就有對SSL協(xié)議各式各樣的攻擊，包括對SSL協(xié)議本身和對SSL協(xié)議應(yīng)用的攻擊。本文主要介紹針對瀏覽器漏洞的中間人攻擊［5］，即 SSL Sniffing攻擊和 SSL Stripping攻擊。

2.1 SSL Sniffing攻擊

SSL Sniffing攻擊解釋為偽裝攻擊［6］，是針對瀏覽器漏洞的攻擊?，F(xiàn)流行的瀏覽器都存在對證書基本約束驗(yàn)證的漏洞，SSL Sniffing攻擊就是利用了這個(gè)薄弱環(huán)節(jié)。證書的基本約束指明了證書鏈的最大允許長度，以及此證書是一個(gè)證書頒發(fā)機(jī)構(gòu)還是一個(gè)終端實(shí)體證書。擁有一個(gè)有效的終端實(shí)體證書的攻擊者，可以利用瀏覽器的這個(gè)漏洞，發(fā)布一個(gè)從屬證書，雖然這個(gè)證書不是由可信的證書頒發(fā)機(jī)構(gòu)頒發(fā)，但是也能通過驗(yàn)證，所以形成了欺騙身份的有效攻擊。

SSL Sniffing攻擊利用一個(gè)ARP欺騙形成一個(gè)中間人攻擊，客戶端（瀏覽器）與服務(wù)器端的直接通信就都會(huì)通過攻擊者，如圖1所示。

圖1 SSL Sniffing攻擊

Attacker利用對證書基本約束驗(yàn)證的漏洞，通過Client的身份認(rèn)證，獲得了Client的信任［7］。SSL Sniffing攻擊利用D－H算法p和g公開，且YC和YS可以被中間人截獲的缺陷發(fā)起攻擊。由于存在中間人攻擊，YC和YS都不能順利到達(dá)指定接收人，而被 Attacker截獲。Client和 Attacker利用YC和YA計(jì)算出會(huì)話密鑰K1，而Server和Attacker利用YS和YA計(jì)算出會(huì)話密鑰K2。對于Client和Server都認(rèn)為是不存在中間人攻擊的安全連接，然而中間人可以透明地截獲所有安全信息。

2.2 SSL Stripping攻擊

通?？蛻舳瞬粫?huì)使用安全的連接打開會(huì)話，只有在需要傳輸敏感數(shù)據(jù)時(shí)，才會(huì)使用安全的SSL連接。SSL Sniffing是針對SSL協(xié)議的應(yīng)用發(fā)起的攻擊。

SSL Stripping攻擊是在客戶端與服務(wù)器端利用ARP欺騙等技術(shù)進(jìn)行一個(gè)中間人攻擊［7－8］，如圖2所示。

圖2 SSL Stripping攻擊

客戶端在瀏覽器中輸入簡單易記的鏈接地址，如 www.security.com，當(dāng)連接上之后，發(fā)現(xiàn)地 址 欄 中 的 地 址 為 https：／／www.security.com／..／..／index.jsp。如圖2所示，對于用戶來說，通常在地址欄中輸入簡短的地址，而不是www.security.com／..／..／index.jsp 這 個(gè) 完 整的地址。攻擊者從HTTP請求消息和響應(yīng)消息開始發(fā)起攻擊。當(dāng)服務(wù)器返回給客戶端一個(gè)重定向 地 址 https：／／www.security.com／..／..／index.jsp，從地址中的https可以看出，服務(wù)器要求客戶端建立一個(gè)安全的SSL連接，但僅僅是在攻擊者和服務(wù)器端建立了一個(gè)安全的連接，而攻擊者將重定向地址修改為http：／／www.security.com／..／..／index.jsp，瀏覽器則根據(jù)這個(gè)地址與攻擊者建立一個(gè)普通的http連接，所有的安全信息對Attacker都是可視未加密的。

3 解決方案

上述2種攻擊方式都是針對瀏覽器漏洞進(jìn)行的攻擊。在SSL Sniffing中，由于D－H算法中的參數(shù)p和g公開，中間人能根據(jù)相同的p和g分別與客戶端和服務(wù)器端建立不同的安全連接，導(dǎo)致不同步；在SSL Stripping中，由于客戶通常在瀏覽器中只輸入簡單易記的網(wǎng)址，而瀏覽器則根據(jù)服務(wù)器的響應(yīng)做永久轉(zhuǎn)移（http 301狀態(tài)）或者暫時(shí)轉(zhuǎn)移（http 302狀態(tài)），所以中間人能修改跳轉(zhuǎn)地址，導(dǎo)致不同步。

3.1 SSL Sniffing攻擊解決方案

為完成密鑰交換，必須在客戶端和服務(wù)器端同步2個(gè)必要參數(shù)p和g。在SSL協(xié)議中，p和g是在相互進(jìn)行身份認(rèn)證的過程中明文傳輸，對整個(gè)網(wǎng)絡(luò)公開。引入可信第三方，由第三方在客戶端和服務(wù)器端同步p和g，以達(dá)到p和g只有客戶端和服務(wù)器端所有。同時(shí)，在客戶端和服務(wù)器端同步一個(gè)用于生成CRC校驗(yàn)碼的生成多項(xiàng)式g（x）。建立模型如圖3所示，其中電信運(yùn)營商為可信第三方，具體步驟如下。

圖3 SSL Sniffing解決方案

（2）Org→Client，Org→Server，p‖g‖g（x）。Org分別用Client和Server的公鑰在雙方同步p、g和g（x）。當(dāng)電信運(yùn)營商接收到Client的會(huì)話請求后，便分別向Client和Server端發(fā)送p、g和g（x），并且用Client和Server的公鑰加密傳輸，保證p、g和g（x）只由通信雙方所有，攻擊 者 無 法 獲 取，即，其中，和分別為Client和Server的公鑰。

（5）Client接收到Server的預(yù)主密鑰，利用g（x）驗(yàn)證有效性，若用g（x）除YS‖ R（YS），余數(shù)不為0，則斷定出錯(cuò)或存在攻擊，不進(jìn)行下一步的連接。驗(yàn)證通過，利用（3）式計(jì)算會(huì)話密鑰K：

（6）Server接收到Client的預(yù)主密鑰，同樣利用g（x）驗(yàn)證有效性，若用g（x）除YC‖R（YC），余數(shù)不為0，則斷定出錯(cuò)或存在攻擊，不進(jìn)行下一步的連接。驗(yàn)證通過，利用（4）式計(jì)算會(huì)話密鑰：

至此整個(gè)解決方案完成。若通過身份驗(yàn)證，則交換密鑰，在客戶端和服務(wù)器端計(jì)算出同樣的一個(gè)會(huì)話密鑰K，用于記錄協(xié)議中的信息加密解密。SSL Sniffing攻擊就是利用網(wǎng)絡(luò)上公開的p和g分別與Client和Sever建立一條安全連接，改進(jìn)后的通信過程同樣由Client端發(fā)起，但與Server建立SSL安全連接之前，Client首先將能識(shí)別Client和Server的ID發(fā)送給可信第三方Org，由Org同步p和g。同時(shí)同步一個(gè)g（x），判斷預(yù)主密鑰是否是對方發(fā)送的預(yù)主密鑰。p和g是Client和Server私有，可以對預(yù)主密鑰進(jìn)行驗(yàn)證。Attacker進(jìn)行中間人攻擊之后，不能與Client和Server進(jìn)行密鑰交換，不能計(jì)算出相同的密鑰，因而不能形成攻擊。

3.2 SSL Stripping攻擊解決方案

為預(yù)防SSL Stripping攻擊，引入數(shù)字簽名技術(shù)和還原重定向地址的思想。

數(shù)字簽名技術(shù)主要應(yīng)用在服務(wù)器端。服務(wù)器端響應(yīng)HTTP請求消息返回響應(yīng)消息時(shí)，對響應(yīng)消息中的重定向地址部分用私鑰進(jìn)行數(shù)字簽名，然后將原重定向地址與簽名結(jié)果連接后發(fā)送給客戶端。還原重定向地址主要應(yīng)用在客戶端?？蛻舳擞梅?wù)器端的公鑰對該重定向地址進(jìn)行驗(yàn)證，若驗(yàn)證不通過，對HTTP響應(yīng)碼做判斷，若是302重定向，則斷定為存在中間人攻擊，還原重定向地址，否則斷定為出現(xiàn)差錯(cuò)或者其他類型攻擊，直接斷開連接。建立模型如圖4所示。

圖4 SSL Stripping解決方案

首先客戶端進(jìn)行數(shù)字簽名的認(rèn)證，其次才是重定向類型的判斷。返回值若為TRUE，表示HTTP響應(yīng)消息中的響應(yīng)碼是302，隨即采取還原重定向地址機(jī)制，否則就斷開連接。具體步驟如下。

（2）Client接收到Redirect響應(yīng)消息，首先對該消息進(jìn)行數(shù)字簽名的認(rèn)證，即利用Server的公鑰對字段進(jìn)行解密：

若解密后的字段與RedirectLocation字段能夠匹配，則判定通過數(shù)字簽名的驗(yàn)證，繼續(xù)進(jìn)行相關(guān)連接，否則數(shù)字簽名驗(yàn)證不能通過，判斷是否需要還原重定向地址。

（3）根據(jù)步驟（2）中數(shù)字簽名的結(jié)果，若不能通過數(shù)字簽名的驗(yàn)證，利用BHO插件對重定向地址類型進(jìn)行判斷，若響應(yīng)消息中的響應(yīng)碼為302，還原重定向地址，同時(shí)與服務(wù)器端建立安全的SSL連接。

解決方案中客戶端對重定向地址的判斷及修改利用的是BHO插件技術(shù)，BHO（Browser Helper Object）即瀏覽器輔助對象。BHO是實(shí)現(xiàn)了特定接口的COM組件，可以開發(fā)自定義功能的瀏覽器插件。編寫代碼使得BHO插件在注冊表中注冊完成，瀏覽器會(huì)根據(jù)注冊表中的插件信息創(chuàng)建實(shí)例，執(zhí)行插件的相關(guān)功能。在瀏覽器的工作過程中，BHO會(huì)接收到瀏覽器的各種事件，如瀏覽新地址、前進(jìn)后退、生成新窗口等等。BHO可以在這些事件的響應(yīng)中實(shí)現(xiàn)與瀏覽器的交互。

在插件開發(fā)過程中，重寫虛函數(shù)OnBeforeNavigate2（），瀏覽器瀏覽新地址之前觸發(fā)該方法。OnBeforeNavigate2（）函數(shù)原型如下所示：

OnBeforeNavigate2函數(shù)在瀏覽器瀏覽新地址之前觸發(fā)，所以對重定向地址的判斷和修改都在該函數(shù)中執(zhí)行。客戶端的BHO插件部分主要有2個(gè)方面的操作，首先判斷是否為302重定向，其次修改重定向地址或者斷開連接，修改重定向地址部分偽代碼如下所示：

其中QueryInfoStatusCode方法是返回HTTP響應(yīng)碼并保存在參數(shù)dwStatusCode中，Navigate2方法是指定瀏覽器導(dǎo)航地址。

斷開連接部分則直接利用OnBeforeNavigate2中的參數(shù)pbCancel。該參數(shù)表示是否繼續(xù)導(dǎo)航。賦值為TRUE表示取消導(dǎo)航，斷開連接，賦值為FALSE表示繼續(xù)導(dǎo)航，進(jìn)行數(shù)據(jù)傳輸。偽代碼如下所示：

當(dāng)HTTP返回碼不是302，且不能通過數(shù)字簽名認(rèn)證，則表示存在其他攻擊，直接斷開連接。

3.3 安全性分析

本文主要針對SSL協(xié)議的2種基于中間人攻擊的攻擊方式提出解決方案，分別是引入可信第三方和數(shù)字簽名技術(shù)以及還原重定向地址的思想，保證了信息傳輸?shù)陌踩浴?/p>

（1）針對SSL Sniffing攻擊，由可信第三方分配D－H算法中的重要參數(shù)，因此p和g只對通信雙方公開，攻擊者完成中間人攻擊之后，不能與客戶端和服務(wù)器端分別建立安全連接，同時(shí)利用CRC校驗(yàn)碼驗(yàn)證預(yù)主密鑰的有效性。

（2）SSL Stripping攻擊主要是修改服務(wù)器的響應(yīng)信息，用普通的http連接取代安全的https連接，迷惑瀏覽器，從而達(dá)到攻擊目的。對于該攻擊原理，為實(shí)現(xiàn)消息同步，在服務(wù)器端和客戶端分別對HTTP響應(yīng)消息進(jìn)行簽名和判斷。服務(wù)器端為防止302重定向地址在傳輸過程中被修改，利用數(shù)字簽名的不可篡改性，將重定向地址與簽名結(jié)果一起發(fā)送給客戶端?？蛻舳耸紫缺仨殞?shù)字簽名進(jìn)行驗(yàn)證，若通過驗(yàn)證，直接進(jìn)行地址的跳轉(zhuǎn)。若不能通過驗(yàn)證，繼續(xù)對HTTP響應(yīng)碼進(jìn)行判斷，若響應(yīng)碼為302，采取還原重定向地址的手段。

4 結(jié)束語

本文對SSL協(xié)議的工作機(jī)制以及密鑰交換算法進(jìn)行了詳細(xì)介紹，同時(shí)針對SSL協(xié)議的2種攻擊方式提出了解決方案。引入可信第三方同步D－H密鑰交換算法中的重要參數(shù)，有效控制了SSL Sniffing攻擊；引入數(shù)字簽名技術(shù)和還原重定向地址的思想，確保瀏覽器跳轉(zhuǎn)之后的連接是安全連接，預(yù)防SSL Stripping攻擊。2種方案都提高了針對瀏覽器漏洞攻擊的安全性。

［1］El－Hajj W.The most recent SSL security attacks：origins，implementation，evaluation，and suggested countermeasures［J］.Security ComMNetworks，2012，5（1）：113－124.

［2］方 勇.信息系統(tǒng)安全理論與技術(shù)［M］.北京：高等教育出版社，2008：125－129.

［3］于寶證，徐樅巍.基于口令的跨服務(wù)器認(rèn)證密鑰交換協(xié)議研究［J］.合肥工業(yè)大學(xué)學(xué)報(bào)：自然科學(xué)版，2007，30（11）：1393－1398.

［4］Li Xin.An improvement of Diffie－Hellman protocol［J］.Network ＆ Computer Security，2007，12：22－23.

［5］Howard M.Man－in－the－Middle attack to the HTTPS protocol［J］.IEEE Computer Society，2009（2）：78－81.

［6］Qin Dong，Zeng Hongliang.Study for client authenticationpolicy based on SSL［J］.Computer Engineering and Design，2008，15（2）：98－101.

［7］Ren Tao，Xie Dongqing.Analysis and research of access control mechanisMbased on SSL protocol［J］.Microcomputer Information，2009，21（3）：112－115.

［8］莫愛民.主流VPN技術(shù)的安全性研究與改進(jìn)［D］.南京：南京理工大學(xué)，2009.