倪健寒++韓嘯

摘要：由于在無線局域網(wǎng)環(huán)境下，ARP Spoof可以輕易完成對客戶端的欺騙，使其誤將攻擊者視為網(wǎng)關(guān)，從而被攻擊者截獲大量明文傳輸?shù)臄?shù)據(jù)報(bào)文。因此，對重要數(shù)據(jù)進(jìn)行加密傳輸?shù)腍TTPS協(xié)議應(yīng)運(yùn)而生。盡管HTTPS協(xié)議采用SSL進(jìn)行加密可以基本杜絕信息泄露，但其并非無懈可擊。SSLStrip利用用戶鍵入網(wǎng)址的習(xí)慣進(jìn)行中間人攻擊就是一個(gè)典型例子。有鑒于此種攻擊的難度低、實(shí)現(xiàn)率高，該文對其進(jìn)行了探究，并基于HTTP Proxy、Cookie Proxy、拓展DHCP給出了相應(yīng)的防范措施。

關(guān)鍵詞：SSLStrip；中間人攻擊；Cookie Proxy；DHCP

中圖分類號：TP393.1 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2016）09-0068-04

1 引言

根據(jù)IEEE802.11協(xié)議簇，工作在2.4Ghz頻段的Wi-Fi能夠提供高達(dá)300-600Mbps傳輸速率的無線網(wǎng)絡(luò)。良好的覆蓋范圍與眾多的應(yīng)用場合使得越來越多的家庭、企業(yè)將其作為接入Internet的首選布網(wǎng)方式。輕便、智能、快捷的同時(shí)卻也帶來了一定的安全隱患。

由于無線信道的共享屬性。所有人均可以在一定工具的幫助下攔截、捕獲、篡改WLAN中傳輸?shù)拿魑臄?shù)據(jù)報(bào)文。其大致方法為：通過ARP Spoof使客戶端誤將攻擊者視為無線局域網(wǎng)中的網(wǎng)關(guān)；然后用同樣的方法使局域網(wǎng)網(wǎng)關(guān)誤將攻擊者視為客戶端；最后便可以抓取客戶端與網(wǎng)關(guān)之間的所有明文數(shù)據(jù)包。這顯然是對用戶隱私的不尊重。

為了保護(hù)用戶重要的數(shù)據(jù)在無線局域網(wǎng)中傳輸時(shí)不被監(jiān)聽，HTTPS協(xié)議應(yīng)運(yùn)而生。由于缺乏有效的SSL證書與正確的密鑰，一個(gè)正在進(jìn)行中的SSL會話是很難被監(jiān)聽和攻擊的。當(dāng)然，這只是在SSL會話正在進(jìn)行的過程中是這樣，那么，如果一個(gè)SSL會話還沒有建立之前也是這樣嗎？考慮一種情形，用戶在鍵入http：//content時(shí)被服務(wù)器要求跳轉(zhuǎn)至相應(yīng)的https：//content網(wǎng)頁，在這一過程中，由于SSL會話尚未建立，所有的數(shù)據(jù)報(bào)文仍然明文傳輸，所以是存在被攻擊的可能的。SSLStrip攻擊就是在這種假設(shè)上完成的。

客觀上講，這種假設(shè)是普遍存在的。人們在訪問一個(gè)網(wǎng)站時(shí)出于便捷的考慮會首選短網(wǎng)址進(jìn)行輸入，而不會在乎http與https的差別。因此，SSLStrip攻擊具有難度低，實(shí)現(xiàn)率高的特點(diǎn)。在防范措施上，宣傳并要求用戶自覺輸入https：//content固然為一種辦法，但是出于減輕用戶負(fù)擔(dān)的考慮，本文進(jìn)一步研究了HTTP Proxy、Cookie Proxy、拓展DHCP這三種防范措施。

HTTP Proxy在客戶端創(chuàng)建了一個(gè)數(shù)據(jù)庫和一定的匹配策略，該數(shù)據(jù)庫會自動(dòng)記錄用戶瀏覽過的所有HTTPS網(wǎng)站的SSL配置信息。當(dāng)用戶再次訪問相同的網(wǎng)站時(shí)會根據(jù)匹配策略比對當(dāng)前網(wǎng)站的SSL配置信息和數(shù)據(jù)庫中的SSL配置信息，得出客戶端是否存在被攻擊的結(jié)論，從而對當(dāng)前訪問的網(wǎng)站做出放行或阻止的行為。鑒于HTTP Proxy數(shù)據(jù)庫無法檢測未訪問過的網(wǎng)站，而且匹配策略也可能較為龐大，本文進(jìn)一步改進(jìn)該方案：將數(shù)據(jù)庫與匹配策略均放置于服務(wù)器端，通過爬蟲自動(dòng)補(bǔ)充SSL配置信息，從而提高匹配精確度。

Cookie Proxy采用了一個(gè)安全cookie 協(xié)議和增設(shè)了安全LAN代理與安全服務(wù)器代理的網(wǎng)絡(luò)拓?fù)?。其防范策略為：如果安全LAN代理檢測到客戶端發(fā)送的是HTTP請求而安全服務(wù)器代理中存儲的相同Cookie ID的set-cookie為HTTPS類型，那么就可以認(rèn)為客戶端已經(jīng)遭受中間人攻擊，請求被立刻拋棄。

拓展DHCP則利用SSLStrip攻擊中必須欺騙客戶端把攻擊者視為網(wǎng)關(guān)這一事實(shí)，利用DHCP確認(rèn)消息在客戶端的ARP緩存中綁定局域網(wǎng)網(wǎng)關(guān)的IP與MAC地址，從而有效阻止攻擊的實(shí)現(xiàn)。

本文的研究思路為：首先介紹與SSLStrip相關(guān)的理論工作，并通過Kali下的實(shí)驗(yàn)予以展現(xiàn)；接著逐一介紹三種防范措施；最后對全文進(jìn)行總結(jié)。

2 SSLStrip的相關(guān)理論與工作

伴隨著互聯(lián)網(wǎng)的不斷發(fā)展，人們越來越多地使用網(wǎng)絡(luò)來進(jìn)行交流和娛樂。然而，在網(wǎng)絡(luò)不斷地融入人們生活方方面面的同時(shí)，網(wǎng)絡(luò)安全問題也漸漸地顯現(xiàn)了出來。近年來，越來越多的網(wǎng)絡(luò)公司開始關(guān)注網(wǎng)絡(luò)安全，例如Google、Baidu這些大型搜索引擎，諸多的電子商務(wù)網(wǎng)站（銀行、郵箱、公司網(wǎng)站等）和大部分政府機(jī)關(guān)網(wǎng)站，都采用了HTTPS來加密用戶與網(wǎng)站服務(wù)器之間的鏈接，從而保障用戶的私密信息不會被盜取。

超文本傳輸安全協(xié)議（HTTPS）是一種網(wǎng)絡(luò)安全傳輸協(xié)議。在計(jì)算機(jī)網(wǎng)絡(luò)上，HTTPS經(jīng)由超文本傳輸協(xié)議（HTTP）進(jìn)行通訊，但利用SSL/TLS來對數(shù)據(jù)包進(jìn)行加密。HTTPS開發(fā)的主要目的是提供對網(wǎng)絡(luò)服務(wù)器的身份認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私與完整性。SSL/TLS，即傳輸層安全協(xié)議，目的是為互聯(lián)網(wǎng)通信，提供安全及數(shù)據(jù)完整性保障。其原理為利用非對稱加密演算來對通訊方做身份認(rèn)證，之后交換對稱密鑰作為會談密鑰（Session key）將通訊雙方交換的數(shù)據(jù)做加密，以保證兩個(gè)應(yīng)用間通信的保密性和可靠性，使客戶與服務(wù)器應(yīng)用之間的通信不被攻擊者竊聽。

SSL/TLS采用TCP傳輸協(xié)議接收和發(fā)送數(shù)據(jù)，并且采用不對稱加密技術(shù)實(shí)現(xiàn)雙方身份的鑒別和信息的秘密完整傳輸。當(dāng)我們建立一個(gè)HTTPS鏈接的時(shí)候，客戶端與服務(wù)器端就開始進(jìn)行握手過程。首先雙方通過交換各自信息來鑒別身份。其中，由客戶端先提供認(rèn)證信息給服務(wù)器端并由服務(wù)器進(jìn)行驗(yàn)證，之后由服務(wù)器返回證書給客戶端驗(yàn)證，待驗(yàn)證通過后雙方將建立起SSL/TLS鏈接并且雙方將通過各自擁有的公鑰私鑰加密證書并生成一個(gè)會話密鑰。最后通過該密鑰進(jìn)行加密會話，從而保證會話內(nèi)容全程加密，不會被第三方監(jiān)聽或干擾。

目前，在瀏覽器、電子郵件、即時(shí)通訊、VoIP、網(wǎng)絡(luò)傳真等應(yīng)用程序中，廣泛支持SSL/TLS協(xié)議。主要的網(wǎng)站，如Google、Facebook、Twitter等也以SSL/TLS協(xié)議來創(chuàng)建安全連接，發(fā)送數(shù)據(jù)。SSL/TLS已成為互聯(lián)網(wǎng)上保密通訊的工業(yè)標(biāo)準(zhǔn)。這很大一部分程度上杜絕了用戶的隱私信息的泄露。然而，HTTPS本身也并非無懈可擊，隨著對HTTPS的研究的不斷深入，針對其的攻擊方法也日漸增多，這些攻擊不僅僅讓用戶的隱私受到威脅，同時(shí)也阻礙了互聯(lián)網(wǎng)安全的發(fā)展。其中最典型的一種攻擊方式就是中間人攻擊（MITM）。

所謂中間人攻擊，是指攻擊者與通訊的兩端分別創(chuàng)建獨(dú)立的聯(lián)系，并交換其所收到的數(shù)據(jù)，使通訊的兩端認(rèn)為他們正在通過一個(gè)私密的連接與對方直接對話，但事實(shí)上整個(gè)會話都被攻擊者完全控制。在中間人攻擊中，攻擊者可以攔截通訊雙方的通話并插入新的內(nèi)容。目前，主流的攻擊方式有SSL劫持攻擊、SSLStrip攻擊以及漏洞攻擊等。由于HTTPS所使用的證書頒發(fā)者必須是經(jīng)過認(rèn)證的對象，因此如果使用SSL劫持攻擊則必須讓用戶信任攻擊者自己簽發(fā)的證書，這使得該攻擊的成功率大大降低。鑒于目前針對HTTPS的漏洞攻擊尚不成熟，本文就著重來探討SSLStrip的攻擊實(shí)現(xiàn)方式，以及針對該類攻擊的防御措施。

SSLStrip，是一種不針對任何程序錯(cuò)誤，而是基于HTTPS體系實(shí)現(xiàn)的攻擊方式。其原理為基于多數(shù)用戶不會主動(dòng)請求SSL協(xié)議來保護(hù)自己和服務(wù)器之間的通信，從而不會主動(dòng)在瀏覽器中輸入https訪問域名。但是由于http跳轉(zhuǎn)https往往是通過服務(wù)器端302重定向?qū)崿F(xiàn)，因此本攻擊方式就抓住了這個(gè)特點(diǎn)，在用戶端接受到跳轉(zhuǎn)信息之前通過明文HTTP協(xié)議去除掉HTTPS跳轉(zhuǎn)的過渡，從而使得原先本應(yīng)被加密的信息都明文呈現(xiàn)在了攻擊者的面前，使得攻擊者能夠自由獲取需要的信息。

具體的實(shí)現(xiàn)步驟如下：

（1） 攻擊者利用ARP欺騙等方式成功監(jiān)聽客戶端；

（2） 客戶端向服務(wù)器端發(fā)送http請求，第三方攻擊者如實(shí)轉(zhuǎn)發(fā)請求；

（3） 服務(wù)器端回復(fù)https鏈接給客戶端，攻擊者收到請求并將該鏈接篡改為http鏈接回復(fù)給客戶端；

（4） 客戶再次發(fā)送http請求給服務(wù)器端，攻擊者將其改為https發(fā)送至服務(wù)器端；

（5） 至此，客戶端與攻擊者就建立了一個(gè)http明文鏈接，攻擊者與服務(wù)器端建立了https加密鏈接，客戶端的所有信息都暴露在了攻擊者的視野之下。

實(shí)現(xiàn)過程展示如下：

3 SSLStrip在Kali上的實(shí)現(xiàn)

實(shí)現(xiàn)步驟如下：

（1）開啟Kali Linux，打開命令行，輸入echo 1 > /proc/sys/net/ipv4/ip_forward打開數(shù)據(jù)包轉(zhuǎn)發(fā)功能；

（2）更改iptables，將所有80端口的TCP數(shù)據(jù)全部轉(zhuǎn)發(fā)至另一未用端口以便監(jiān)聽（圖中設(shè)定8080端口）；

（3）輸入ifconfig，查看本機(jī)的ip并且確認(rèn)自己即將攻擊的主機(jī)的ip以及自己所處局域網(wǎng)內(nèi)的路由器的ip地址；

（4）利用Ettercap工具進(jìn)行ARP欺騙。根據(jù)步驟3的信息，首先選擇需要嗅探的網(wǎng)卡，此處為eth0，因此選擇sniff > unified sniffing > eth0，之后掃描需要被攻擊的Host，選擇Hosts > scan for hosts >hosts list。選擇Target 1，即剛剛選定的需要攻擊的主機(jī)IP（此處為192.168.1.111），Target 2，即網(wǎng)關(guān)IP（此處為192.168.1.1），實(shí)現(xiàn)雙向欺騙從而能夠監(jiān)聽雙向的數(shù)據(jù)包；

（5）待成功進(jìn)行ARP欺騙后，打開sslstrip開始監(jiān)聽8080端口，輸入：sslstrip –p –l 8080。

（6）之后另開一個(gè)命令行，鍵入tail -F sslstrip.log查看監(jiān)聽日志；

從上圖中可以看到，針對豆瓣的登陸網(wǎng)址（accounts.douban.com），客戶端發(fā)送的信息原本是以https協(xié)議加密傳輸，被全部轉(zhuǎn)換至http明文并成功被SSLStrip監(jiān)聽和記錄（form_email=123@126.com&form_password=123456），并且客戶端沒有任何錯(cuò)誤或警告信息提示。

至此，一個(gè)完整的SSLStrip攻擊過程結(jié)束，第三方攻擊者成功獲取到了用戶的登錄信息并且客戶端沒有發(fā)現(xiàn)任何異常。

由此可見，SSLStrip的攻擊方式非常簡單，只需利用ARP欺騙監(jiān)聽同一網(wǎng)段下的受害者主機(jī)和網(wǎng)關(guān)，將所有主機(jī)到網(wǎng)關(guān)的HTTPS協(xié)議數(shù)據(jù)包篡改為HTTP協(xié)議的數(shù)據(jù)包即可實(shí)現(xiàn)數(shù)據(jù)的獲取。經(jīng)過多次的測試，我們發(fā)現(xiàn)很多大型郵箱服務(wù)網(wǎng)站（163.com、126.com、mail.qq.com等）都可以通過SSLStrip攻擊獲取用戶的賬號密碼。由于沒有使用SSL劫持攻擊，所以不會產(chǎn)生瀏覽器證書報(bào)錯(cuò)或是HTTPS協(xié)議中包含HTTP明文內(nèi)容的問題，從而能讓用戶在絲毫都沒有察覺到信息被監(jiān)聽的情況下獲取到用戶的隱私。可以看出，整個(gè)攻擊的行為應(yīng)用了多種協(xié)議的攻擊手段，效果非常明顯。

當(dāng)然，除了ARP欺騙受害者主機(jī)與網(wǎng)關(guān)這種方式以外，還可以通過其他方式來截獲數(shù)據(jù)包并進(jìn)行篡改，例如DNS欺騙、設(shè)置代理等?？偠灾ㄟ^多種方式攻擊方式結(jié)合SSLStrip，可以成功將原本用戶端發(fā)送的HTTPS加密的內(nèi)容轉(zhuǎn)換為HTTP明文內(nèi)容，并被第三方攻擊者監(jiān)聽獲取。所以說，防范SSLStrip此類攻擊方式，顯得非常重要。

4 基于HTTP Proxy的防范措施

HTTP Proxy的核心為數(shù)據(jù)庫和匹配規(guī)則。傳統(tǒng)上，數(shù)據(jù)庫與匹配規(guī)則均存儲在客戶端中，數(shù)據(jù)庫負(fù)責(zé)記錄瀏覽過的所有HTTPS站點(diǎn)的SSL配置信息，匹配規(guī)則負(fù)責(zé)比對當(dāng)前瀏覽的網(wǎng)站所使用的SSL配置信息與數(shù)據(jù)庫中的配置信息，從而做出客戶端是否已經(jīng)遭受中間人攻擊的結(jié)論。為了提高效率與精確率，本文認(rèn)為：可以將數(shù)據(jù)庫與匹配規(guī)則均放置于服務(wù)器端，由爬蟲定期更新SSL配置信息與匹配規(guī)則，從而減輕客戶端負(fù)擔(dān)。

由于傳統(tǒng)的HTTP Proxy建立在客戶端，因此存在如下假設(shè)：用戶在大多數(shù)情況下都處在安全的網(wǎng)絡(luò)環(huán)境之下，由此擁有足夠的樣本去建立一個(gè)數(shù)據(jù)庫，告訴客戶端在當(dāng)前瀏覽的網(wǎng)站中，應(yīng)該存在或不存在什么特征。從而為匹配規(guī)則建立相應(yīng)的基礎(chǔ)。基于此種特征，該防范策略將同樣適用于動(dòng)態(tài)網(wǎng)站。

History Proxy中內(nèi)嵌三個(gè)模塊，分別是：分析模塊，用來解析瀏覽器發(fā)出的請求以及服務(wù)器的響應(yīng)信息；檢測模塊，用來監(jiān)測不符合檢測規(guī)則的所有請求和回應(yīng)，從而認(rèn)定當(dāng)前頁面是否安全；私密數(shù)據(jù)跟蹤模塊，在中間人檢測器出錯(cuò)的情況下用來防止私密數(shù)據(jù)的泄露。

其中，私密數(shù)據(jù)跟蹤模塊基于以下事實(shí)做出判斷：所有登陸框都應(yīng)使用HTTPS進(jìn)行傳輸，因此，如果在HTTP數(shù)據(jù)流中發(fā)現(xiàn)用戶鍵入的賬號密碼，那么，我們就可以斷定攻擊者繞過了客戶端的HTTP Proxy檢測規(guī)則。此時(shí)只要斷開連接即可避免損失。根據(jù)上述描述，我們在客戶端增加一段JavaScript代碼，將用戶在登陸框中鍵入的賬號密碼加密后發(fā)送至HTTP Proxy的一個(gè)數(shù)組中。之后，私密數(shù)據(jù)跟蹤模塊將檢查所有POST出去的數(shù)據(jù)，如發(fā)現(xiàn)存在與數(shù)組中存儲的私密數(shù)據(jù)相匹配的明文賬號密碼則立刻斷開該鏈接。

下面針對不同的HTTP消息談?wù)摍z測模塊所應(yīng)包含的規(guī)則：

①HTTP Moved消息：如果攻擊者能夠成功阻止Moved消息，那么將導(dǎo)致HTTP跳轉(zhuǎn)HTTPS無法完成。表1列舉了可能的修改以及它們是否被檢測規(guī)則所允許：

表1 HTTP Moved Messages 檢測規(guī)則

[當(dāng)前響應(yīng)＼& 修改情況以及是否允許＼&跳轉(zhuǎn)到HTTPS域名＼&無修改，允許跳轉(zhuǎn)＼&跳轉(zhuǎn)到HTTPS域名＼&修改Page，允許跳轉(zhuǎn)＼&跳轉(zhuǎn)到HTTP 域名＼& 非SSL協(xié)議，不允許跳轉(zhuǎn)＼&跳轉(zhuǎn)到HTTP 域名＼& 修改了的域名，不允許＼&跳轉(zhuǎn)到HTTPS域名＼& 修改了的域名，不允許＼&OK....＼& HTML代替MOVED，不允許＼&]

②JavaScript：由于JavaScript可以被用來在頁面中讀取用戶鍵入的字符串。所以，我們應(yīng)當(dāng)對一個(gè)HTTPS頁面中所有的JavaScript（包括內(nèi)部與外部的）的執(zhí)行過程予以記錄，從而與當(dāng)前的HTTPS頁面進(jìn)行比較，判斷是否有額外加入或篡改的JavaScript 。一旦檢測到這種情況就應(yīng)當(dāng)對用戶發(fā)出警告。

③Iframe Tags：由于Iframe Tags可以將一個(gè)偽造的登錄框覆蓋到原始的登錄框之上。因此，一旦數(shù)據(jù)庫中的信息表示該網(wǎng)頁在此處不應(yīng)當(dāng)有Iframe Tags時(shí)，我們就應(yīng)該阻止該段代碼的執(zhí)行。

④HTTP Forms：由于增加的表單可能會誘導(dǎo)用戶泄露私密信息，所以，我們在檢測規(guī)則中對HTTP Forms采取如下策略：

（1）表單缺失：如果HTTP Proxy發(fā)現(xiàn)頁面缺失安全登陸表單，則提出警告，建議終止會話。

（2）新表單：如果新表單為登陸框，發(fā)出警告；若不是，檢測該表單是否采取加密傳輸并與其他表單指向相同安全域名。

（3）表單篡改：當(dāng)HTTP Proxy發(fā)現(xiàn)表單由HTTPS轉(zhuǎn)向HTTP或者表單所指向的目標(biāo)域名發(fā)生變化，則提出警告。

對于實(shí)時(shí)變化額動(dòng)態(tài)網(wǎng)站，我們做如下處理：

（1）對網(wǎng)頁進(jìn)行抽象：HTTP Proxy在首次訪問一個(gè)網(wǎng)頁時(shí)做兩次相同的請求。比較兩次請求的相應(yīng)，若不同，記錄相同部分的配置以及不同部分的配置變化域，將這些信息記錄到數(shù)據(jù)庫供檢測模塊比對。

（2）JavaScript認(rèn)證：對網(wǎng)站上使用的JavaScript進(jìn)行簽名，從而認(rèn)證該網(wǎng)頁所使用的JavaScript沒有被篡改過。

5 基于Cookie Proxy的防范措施

目前的Cookie機(jī)制可以描述如下：

（1）客戶端發(fā)送HTTP（S）請求到服務(wù)器端；

（2）服務(wù)器端生成set-cookie發(fā)送至客戶端；

（3）客戶端生成一個(gè)cookie并存儲；

（4）客戶端將cookie發(fā)送至服務(wù)器端；

（5）服務(wù)器端予以響應(yīng)。

Cookie Proxy采用了一個(gè)安全Cookie 協(xié)議和增設(shè)了安全LAN代理與安全服務(wù)器代理的網(wǎng)絡(luò)拓?fù)洹０踩獵ookie協(xié)議的主要作用為判斷當(dāng)前使用的是HTTP還是HTTPS進(jìn)行數(shù)據(jù)傳輸。該協(xié)議工作在安全LAN代理與安全服務(wù)器代理之間。我們將安全Cookie協(xié)議表示如圖3所示：

說明：expires：有效期；EK（data）：使用密鑰K加密data；

HMACK密鑰為K的data的哈希消息認(rèn)證碼。

圖3中的SN為HTTPS標(biāo)志，當(dāng)SN的值為secure時(shí)，我們認(rèn)為當(dāng)前傳輸協(xié)議為HTTPS。CID即Cookie ID，為標(biāo)志該Cookie的隨機(jī)數(shù)。我們建立如圖拓?fù)洹?/p>

根據(jù)該拓?fù)?，WLAN中客戶端的所有數(shù)據(jù)報(bào)文均經(jīng)過SLGP過濾后再轉(zhuǎn)發(fā)至網(wǎng)關(guān)。同樣，服務(wù)器端所有的數(shù)據(jù)報(bào)文也是通過SSGP轉(zhuǎn)發(fā)到其所在的網(wǎng)關(guān)。Cookie Proxy的運(yùn)行機(jī)制為：如果SLGP發(fā)現(xiàn)客戶端請求的傳輸類型為HTTP而SLGP中存儲的具有相同CID的set-cookie為secure類型，那么SLGP將拒絕該次請求。

綜述，我們將Cookie Proxy運(yùn)行流程歸納如下：

（1）客戶端將一個(gè)請求發(fā)送到SSGP；

（2）SSGP 接收到請求，從中解析出Cookie并驗(yàn)證該Cookie是否有效。如果有效，將請求轉(zhuǎn)發(fā)至服務(wù)器組。

（3）服務(wù)器根據(jù)接收到的請求生成set-cookie，將set-cookie發(fā)送至SSGP。

（4）SSGP 將set-cookie進(jìn)行封裝，發(fā)送至SLGP。

（5）SLGP接收到SSGP發(fā)送的set-cookie，驗(yàn)證簽名，如果有效就發(fā)送至客戶端。

（6）客戶端將接收到的set-cookie進(jìn)行存儲。

（7）客戶端根據(jù)存儲的set-cookie生成一個(gè)新的cookie并發(fā)送請求。

（8）返回第一步。

6 基于拓展DHCP的防范措施

在說明拓展DHCP之前，本文首先介紹一下目前DHCP協(xié)議中對DHCP ACK消息采取的規(guī)范。根據(jù)RFC2132，DHCP ACK消息中包含的配置信息有：IP Address、Net Mask、Default Gateway、DNS Sever等。但由于不存在對MAC Address的描述，所以我們無法通過DHCP ACK信息對局域網(wǎng)網(wǎng)關(guān)的IP-MAC關(guān)系進(jìn)行綁定。ARP欺騙也因此容易成功。本文在查閱DHCP ACK報(bào)文結(jié)構(gòu)之后發(fā)現(xiàn)，我們可以在ACK報(bào)文的一個(gè)可選項(xiàng)NIS （Network Information Service） 中加入相應(yīng)的MAC消息完成網(wǎng)關(guān)綁定。

圖5為拓展DHCP對NIS的一個(gè)結(jié)構(gòu)設(shè)想：

根據(jù)協(xié)議，NIS的Code為40，由于NIS Domain Name中封裝的是MAC Address，所以長度我們設(shè)置為6。從圖5中可以推斷該局域網(wǎng)內(nèi)的網(wǎng)關(guān)的MAC 地址為3f-06-1e-5c-03-05。為進(jìn)一步說明拓展DHCP的工作流程，我們構(gòu)建如下拓?fù)洌?/p>

在拓展DHCP網(wǎng)絡(luò)拓?fù)渲?，DHCP服務(wù)器將局域網(wǎng)網(wǎng)關(guān)的IP-MAC關(guān)系通過重新設(shè)想的DHCP ACK消息告知客戶端?？蛻舳私邮盏紻HCP服務(wù)器傳送過來的DHCP ACK消息之后首先進(jìn)行簽名驗(yàn)證，驗(yàn)證通過后會將NIS字段和IP Address字段進(jìn)行解析，之后將解析到的信息寫入ARP緩存，從而完成網(wǎng)關(guān)的IP-MAC關(guān)系綁定。這樣便可以有效避免ARP欺騙，并進(jìn)一步制止SSLStrip的攻擊。

7 論文總結(jié)與展望

本文在介紹了SSL工作機(jī)制之后對在其之上建立的HTTPS傳輸協(xié)議進(jìn)行了分析，指出在網(wǎng)頁由HTTP跳轉(zhuǎn)HTTPS的過程中存在可以被中間人攻擊所利用的漏洞。對于該漏洞的利用，本文以SSLStrip為例進(jìn)行了展示。

由于該種攻擊方式難度低、成功率高、防范少，本文隨后重點(diǎn)分析了三種防范此類攻擊的措施。第一種措施以HTTPS頁面的配置信息比對結(jié)果為參考，重點(diǎn)在于檢測規(guī)則的完善與精確。第二種措施通過Cookie中的SN字段判斷傳輸類型是HTTP還是HTTPS，從而檢測出本該請求HTTPS頁面而實(shí)際獲得HTTP頁面的情形。這樣便可以及時(shí)阻止該次攻擊。第三種措施通過拓展DHCP在客戶端的ARP緩存中綁定局域網(wǎng)網(wǎng)關(guān)的IP-MAC關(guān)系，從而有效制止基于ARP Spoof的SSLStrip攻擊。

本文認(rèn)為，由于HTTPS通信的開銷相對較大，且用戶在大多數(shù)情況下還是處于一個(gè)相對安全的網(wǎng)絡(luò)環(huán)境之中的。所以，額外的攻擊檢測將使網(wǎng)絡(luò)的負(fù)載更大。如何權(quán)衡開銷更小的攻擊檢測與防范策略還需要我們進(jìn)一步予以探究。

參考文獻(xiàn)：

[1] 王立彥. HTTPS協(xié)議中間人攻擊的實(shí)現(xiàn)與防御[D]. 東北大學(xué)，2011.

[2] 趙森棟.安全套接層中間人攻擊與防護(hù)研究[D]. 哈爾濱工程大學(xué)，2013.

[3] Yan zhao. A New Strategy to Defense against SSLStrip for Android[J]. Proceedings of ICCT2013，2013：70-74.

[4] Marlinspike M. More Tricks for Defeating SSL in Practice. In Black Hat USA，2009.

[5] Marlinspike M. New tricks for defeating ssl in practice，2009.

[6] Callegati F， Cerroni W， Ramilli M. Man-in-the-Middle Attack to the HTTPS Protocol[J]. Security Privacy. 2009， 7（1）：78-81.

[7] Chen Z， Guo S， Zheng K. Modeling of man-in-the-middle attack in the wireless networks. Wireless Communications， Networking and Mobile Computing，2007： 21-25.

[8] Seung Yeob Nam， Dongwon Kim， Jeongeun Kim. Enhanced ARP： Preventing ARP Poisoning-Based Man-in-the-Middle Attacks[J]. Communications Letters， IEEE， 2010， 14（2）：187-189.