本站小編為你精心準(zhǔn)備了安全協(xié)議的安全性分析參考范文，愿這些范文能點(diǎn)燃您思維的火花，激發(fā)您的寫作靈感。歡迎深入閱讀并收藏。

《計(jì)算機(jī)工程與科學(xué)雜志》2014年第六期

1ssl協(xié)議概述

ssl協(xié)議由HandsHakeProtocol、CHangeCi—pHerspeCProtocol、alertProtocol以及reCordProtocol組成。其中，HandsHakeProtocol、CHangeCipHerspeCProtocol和alertProtocol這三個(gè)協(xié)議位于tCp／ip協(xié)議棧的應(yīng)用層。reCordProtocol介于應(yīng)用層和傳輸控制層之間。ssl協(xié)議與tCp／ip協(xié)議的體系結(jié)構(gòu)如圖2所示。ssl協(xié)議中，ssl會(huì)話和ssl連接是兩個(gè)重要的概念。ssl連接是指能夠提供一種服務(wù)的傳輸方式。對(duì)于ssl協(xié)議來說，這樣的連接是對(duì)等體之間的，即客戶端與服務(wù)器模式。ssl會(huì)話是存在于客戶端與服務(wù)器之間的一種聯(lián)系，它為ssl連接規(guī)定了一組密碼元件。相對(duì)于ssl會(huì)話，ssl連接是暫時(shí)的。每個(gè)ssl連接對(duì)應(yīng)一個(gè)ssl會(huì)話。在ssl協(xié)議中，由于ssl會(huì)話的建立需要的計(jì)算量較大，為了使協(xié)議的運(yùn)行效率提高，一個(gè)ssl會(huì)話通常對(duì)應(yīng)多個(gè)不同的ssl連接。下面簡單地介紹一下HandsHakeProtocol、CHangeCipHerspeCProtocol、alertProtocol以及reCordProtocol四個(gè)協(xié)議的內(nèi)容。（1）HandsHakeProtocol（握手協(xié)議）。sslHandsHakeProtocol是ssl協(xié)議中最復(fù)雜的部分，也是本文的攻擊重點(diǎn)，這里有必要詳述其流程。HandsHakeProtocol的流程如圖3所示。HandsHakeProtocol的流程大致可分為四個(gè)階段：構(gòu)建安全參數(shù)；服務(wù)器認(rèn)證及密鑰交換；客戶端認(rèn)證及密鑰交換；結(jié)束。下面對(duì)其進(jìn)行一一闡述。階段1構(gòu)建安全參數(shù)。這一階段用于初始化一個(gè)邏輯上的連接，并在連接上定義安全參數(shù)。首先由客戶端發(fā)送Clien—tHello給服務(wù)器。其中，ClientHello包含下面五個(gè)參數(shù)：上述五個(gè)參數(shù)的詳細(xì)內(nèi)容請(qǐng)參閱文獻(xiàn)［1］。服務(wù)器收到ClientHello后，發(fā)送serverHello給客戶端。serverHello的參數(shù)類似于ClientHello的五個(gè)參數(shù)。需要注意的是，serverHello中的CipHer—suite的選定取決于ClientHello中的CipHersuite提供的一組密碼及密鑰交換算法，且只能選定其中的一套密碼及密鑰交換算法。此外，3．0版本的ssl協(xié)議中的CompressionmetHod默認(rèn)值為null。本文的攻擊對(duì)象為CipHersuite選定的密鑰交換算法，需對(duì)其詳述。客戶端支持的密鑰交換算法如下所述：①rsa：密鑰使用服務(wù)器的rsa公鑰加密。客戶端擁有服務(wù)器rsa公鑰的公鑰證書，公鑰證書由可信任的證書機(jī)構(gòu)簽發(fā)。②固定的diffie—Hellman：這是diffie—Hell—man密鑰交換算法。服務(wù)器的證書包含diffie—Hellman密鑰交換算法中的服務(wù)器公鑰，該證書由可信任的證書機(jī)構(gòu)簽發(fā)。如果服務(wù)器要求其發(fā)送證書，客戶端可在其證書中提供客戶端的diffie—Hellman公鑰；如果不發(fā)送證書，可在密鑰交換信息中發(fā)送客戶端公鑰。③短暫的diffie—Hellman：類似于固定的dif—fie—Hellman，服務(wù)器傳給客戶端證書的同時(shí)，還有服務(wù)器使用rsa的私鑰對(duì)diffie—Hellman公鑰的簽名。④匿名diffie—Hellman：這也是diffie—Hell—man密鑰交換算法。服務(wù)器和客戶端雙方通過密鑰交換信息將各自的diffie—Hellman公鑰發(fā)送給對(duì)方，不需要認(rèn)證。⑤fortezza：fortezza方案的密鑰交換算法。階段2服務(wù)器認(rèn)證及密鑰交換。如果上一階段需要服務(wù)器被認(rèn)證，服務(wù)器將CertifiCate證書發(fā)送給客戶端。除了匿名diffie—Hellman密鑰交換，其余四種密鑰交換都需要認(rèn)證證書。接著，服務(wù)器只在下列三種情況下發(fā)送serverkeyexCHange消息：①fortezza。②匿名diffie—Hellman：消息中包含一個(gè)大素?cái)?shù)，一個(gè)關(guān)于該素?cái)?shù)的原根以及服務(wù)器的diffie—Hellman公鑰。③短暫的diffie—Hellman：消息中除了匿名diffie—Hellman的三個(gè)元素外，還有關(guān)于該三個(gè)元素的簽名。需要被認(rèn)證的服務(wù)器發(fā)送CertifiCaterequest給客戶端，要求客戶端的CertifiCate。最后，服務(wù)器發(fā)送serverHellodone給客戶端。階段3客戶端認(rèn)證及密鑰交換。如果在階段2要求了客戶端的證書，此時(shí)，客戶端發(fā)送CertifiCate給服務(wù)器。接著，客戶端發(fā)送ClientkeyexCHange消息給服務(wù)器。該消息的內(nèi)容取決于密鑰交換的方式：①rsa：客戶端生成48—byte的pre—masterkey，使用服務(wù)器的rsa公鑰證書中的公鑰對(duì)pre—masterkey加密。②短暫的或匿名diffie—Hellman：客戶端的diffie—Hellman公鑰。③固定的diffie—Hellman：客戶端的diffie—Hellman公鑰包含在客戶端CertifiCate中，因此內(nèi)容是空的。④fortezza：客戶端的fortezza參數(shù)。最后，客戶端可能發(fā)送CertifiCateverify消息給服務(wù)器，用于服務(wù)器驗(yàn)證客戶端CertifiCate。階段4結(jié)束。客戶端發(fā)送CHangeCipHerspeC消息給服務(wù)器，值得注意的是，該消息是客戶端利用CHangeCipHerspeCProtocol發(fā)送的，不屬于HandsHakeProtocol。之后，客戶端使用協(xié)商好的密碼算法及密鑰對(duì)finisHed消息加密，并將密文發(fā)送給服務(wù)器。服務(wù)器利用CHangeCipHerspeCProtocol發(fā)送CHangeCipHerspeC消息給客戶端，服務(wù)器同樣使用協(xié)商好的密碼算法及密鑰對(duì)finisHed消息加密，并將密文發(fā)送給客戶端。到此，客戶端與服務(wù)器的安全連接建立完畢，二者可利用協(xié)商好的密碼算法及密鑰進(jìn)行保密通信了。（2）reCordProtocol（記錄層協(xié)議）。sslreCordProtocol為ssl連接提供了兩種服務(wù)：①機(jī)密性。sslHandsHakeProtocol定義了一個(gè)分組密碼或流密碼的加密共享密鑰，sslre—CordProtocol利用共享密鑰和常規(guī)的分組密碼或流密碼算法對(duì)ssl的有效載荷進(jìn)行加密。②消息完整性。sslHandsHakeProtocol定義了一個(gè)maC（消息認(rèn)證碼）共享密鑰，sslre—CordProtocol利用該maC共享密鑰和HasH函數(shù)生成了關(guān)于消息的消息認(rèn)證碼。sslreCordProtocol對(duì)應(yīng)用層的數(shù)據(jù)進(jìn)行分段、壓縮（可選項(xiàng)）、計(jì)算maC、加密、添加sslre—CordProtocol的報(bào)頭，最后將結(jié)果加入tCp段中。（3）CHangeCipHerspeCProtocol（改變密碼規(guī)范協(xié)議）。CHangeCipHerspeCProtocol只包含一個(gè)字節(jié)的信息，該字節(jié)的值為1。該字節(jié)的信息利用sslreCordProtocol的當(dāng)前密碼算法和密鑰加密。加了密的信息在客戶端和服務(wù)器之間傳輸，雙方解密之后獲得信息，之后的sslreCordproto—Col中的數(shù)據(jù)將由剛協(xié)商好的密碼算法及密鑰進(jìn)行加密傳輸。（4）alertProtocol（警告協(xié)議）。在alertProtocol中，大多數(shù)的alert消息都是毀滅性的，它告訴接受者（客戶端或服務(wù)器）立即中斷會(huì)話。例如，Close＿notify消息表明發(fā)送者已完成在連接上發(fā)送應(yīng)用程序的數(shù)據(jù)。詳述請(qǐng)參閱文獻(xiàn)。

2ssl協(xié)議的安全性分析

客戶端和服務(wù)器利用ssl協(xié)議在不安全的鏈路中建立一條安全的連接通道。通過本文對(duì)ssl協(xié)議的闡述可知，影響ssl協(xié)議安全實(shí)施的關(guān)鍵在于HandsHakeProtocol。下面對(duì)于HandsHakeProtocol做進(jìn)一步的安全分析。由文中的第2節(jié)可知，HandsHakeProtocol中的認(rèn)證及密鑰交換部分是影響安全的主要因素。認(rèn)證完成，密鑰建立之后，客戶端和服務(wù)器就能安全地進(jìn)行保密通信。在這種情況下，攻擊者的攻擊就是針對(duì)已知分組密碼或流密碼的攻擊，即對(duì)算法本身的攻擊。而這種攻擊通常采用暴力攻擊，針對(duì)某一特定的密文，采用窮搜索密鑰空間，找尋合適的明文。暴力攻擊對(duì)攻擊者的計(jì)算資源的要求非常高。在HandsHakeProtocol中，對(duì)于不同的認(rèn)證方式，有與之相對(duì)應(yīng)的密鑰交換方式。HandsHakeProtocol支持三種認(rèn)證方式：客戶端和服務(wù)器的雙方認(rèn)證；服務(wù)器的單方認(rèn)證；客戶端和服務(wù)器的完全匿名認(rèn)證。對(duì)于rsa公鑰證書，采取第一種方式認(rèn)證，認(rèn)證通過后，接收方（客戶端或服務(wù)器）利用發(fā)送方（客戶端或服務(wù)器）證書中的rsa公鑰對(duì)密鑰進(jìn)行加密后傳給發(fā)送方，發(fā)送方利用對(duì)應(yīng)的rsa私鑰解密獲得密鑰；采取第二種方式，客戶端在驗(yàn)證服務(wù)器的身份后，利用服務(wù)器證書中的rsa公鑰對(duì)密鑰進(jìn)行加密，密文通過消息ClientkeyexCHange發(fā)送給服務(wù)器，服務(wù)器利用對(duì)應(yīng)的rsa私鑰解密密文獲得密鑰。在這種情況下，攻擊者想獲得解密私鑰的難度等同于大數(shù)分解，因此密鑰是安全的。對(duì)于固定的diffie—Hellman公鑰證書，采用第一種認(rèn)證方式。服務(wù)器和客戶端分別向?qū)Ψ桨l(fā)送包含diffie—Hellman公鑰的證書，認(rèn)證結(jié)束后，各自利用自己的私鑰與對(duì)方的diffie—Hellman公鑰計(jì)算出密鑰。在這種情況下，攻擊者想獲得私鑰的難度等同于計(jì)算離散對(duì)數(shù)，因此密鑰是安全的。對(duì)于短暫的diffie—Hellman密鑰交換，采用第二種認(rèn)證方式。服務(wù)器生成rsa公鑰／私鑰對(duì)，利用私鑰對(duì)服務(wù)器diffie—Hellman公鑰簽名，服務(wù)器生成關(guān)于rsa公鑰的公鑰證書，服務(wù)器將公鑰證書、diffie—Hellman公鑰以及關(guān)于diffie—Hellman公鑰的簽名發(fā)送給客戶端。客戶端驗(yàn)證完服務(wù)器的身份后，利用證書中的公鑰就能驗(yàn)證簽名的合法性，從而知道diffie—Hellman公鑰是由服務(wù)器發(fā)送過來的。客戶端利用自己的私鑰與服務(wù)器diffie—Hellman公鑰生成密鑰。在這種情況下，攻擊者想獲得簽名私鑰的難度等同于大數(shù)分解，因此攻擊者無法偽造關(guān)于diffie—Hellman公鑰的合法簽名。對(duì)于匿名diffie—Hellman密鑰交換，采用第三種認(rèn)證方式。服務(wù)器和客戶端在不認(rèn)證對(duì)方身份的情況下，直接將各自的diffie—Hellman公鑰傳給對(duì)方，之后，各自利用自己的私鑰與對(duì)方的diffie—Hellman公鑰計(jì)算出密鑰。在這種情況下，攻擊者想獲得私鑰的難度等同于計(jì)算離散對(duì)數(shù)，因此密鑰是安全的。綜上所述，ssl協(xié)議總體上是安全的，協(xié)議的不安全是由于實(shí)現(xiàn)者在配置和實(shí)現(xiàn)ssl協(xié)議于客戶端和服務(wù)器時(shí)，實(shí)現(xiàn)者考慮不周或工業(yè)化制定標(biāo)準(zhǔn)過時(shí)等因素造成的。

3ssl協(xié)議漏洞分析

通過對(duì)ssl協(xié)議本身的深入研究與分析，該協(xié)議從理論上來說存在四個(gè)漏洞，并且通過測(cè)試驗(yàn)證了＊＊＊模式漏洞的實(shí)際存在性。下面對(duì)這四個(gè)漏洞分別闡述。（1）＊＊＊模式漏洞。＊＊＊模式漏洞是指配置有ssl協(xié)議的客戶端和服務(wù)器都支持＊＊＊密碼套件。通過搭建實(shí)驗(yàn)環(huán)境驗(yàn)證了＊＊＊模式漏洞的存在性，并通過編制的工具sslClient測(cè)試了國內(nèi)的某些安全郵箱服務(wù)器存在＊＊＊模式漏洞。因而對(duì)于具備一定硬件條件的攻擊者而言，攻擊者利用＊＊＊模式漏洞，可以實(shí)施針對(duì)ssl協(xié)議的攻擊，或者實(shí)施針對(duì)利用ssl協(xié)議構(gòu)建的安全郵箱服務(wù)器的攻擊。下面簡單介紹實(shí)現(xiàn)＊＊＊模式漏洞挖掘的主要思路、實(shí)驗(yàn)環(huán)境以及攻擊過程。①技術(shù)實(shí)現(xiàn)的主要思路。攻擊主要采用中間者攻擊技術(shù)（man—in—tHe—middleattaCk），其思路如圖4所示。這里，對(duì)圖4簡單地描述一下：在有網(wǎng)關(guān)的局域網(wǎng)中，a發(fā)往s的數(shù)據(jù)包必然要先發(fā)到網(wǎng)關(guān)g，再通過g進(jìn)行轉(zhuǎn)發(fā)；同樣，s發(fā)往a的數(shù)據(jù)包也要先發(fā)到網(wǎng)關(guān)g，再通過g發(fā)送到a。我們需要實(shí)現(xiàn)的就是中間者m攔截從a發(fā)往g的數(shù)據(jù)包。注意這里攔截和截獲的意思是不同的：中間者m截獲數(shù)據(jù)包只是對(duì)傳輸?shù)臄?shù)據(jù)包進(jìn)行復(fù)制；中間者m攔截?cái)?shù)據(jù)包不但能獲得數(shù)據(jù)包的復(fù)制，而且能決定是否繼續(xù)數(shù)據(jù)包1080Computerengineering＆sCienCe計(jì)算機(jī)工程與科學(xué)2014，36（6）的傳輸，或?qū)?shù)據(jù)包修改后再進(jìn)行傳輸。②技術(shù)實(shí)現(xiàn)的實(shí)驗(yàn)環(huán)境。a電腦一臺(tái)，宿主機(jī)安裝WindowsXp操作系統(tǒng)。宿主機(jī)中安裝一個(gè)Windows2000虛擬機(jī)作為ssl的客戶端，安裝一個(gè)Windows2000虛擬機(jī)作為ssl的服務(wù)器。b搭建局域網(wǎng)環(huán)境。將宿主機(jī)WindowsXp的ip地址設(shè)為192．168．19．1，ssl客戶端的ip地址設(shè)為192．168．19．5，ssl服務(wù)器的ip地址設(shè)為192．168．19．4，三臺(tái)機(jī)器構(gòu)成一個(gè)局域網(wǎng)絡(luò)。C宿主機(jī)中運(yùn)行開發(fā)的mim＿ssl中間者工具，WiresHark網(wǎng)絡(luò)數(shù)據(jù)包分析器；ssl客戶端使用微軟的ie瀏覽器；ssl服務(wù)器安裝apaCHe2．2服務(wù)器。使用openssl—0．9．8m開發(fā)庫開發(fā)。實(shí)驗(yàn)環(huán)境如圖5所示。通過截獲并篡改客戶端與服務(wù)器之間的ssl數(shù)據(jù)包，使得客戶端與服務(wù)器同時(shí)支持＊＊＊模式，從而中間者截獲客戶端發(fā)給服務(wù)器的Client—keyexCHange消息，該消息中包含ssl通聯(lián)中的預(yù)主密鑰，由于中間者具備破解＊＊＊的能力，中間者能夠獲得預(yù)主密鑰，因此中間者具備了掌控ssl通聯(lián)過程的條件，由此獲得有用的信息。（2）dHe密鑰交換的漏洞［8］。攻擊者通過改變服務(wù)器密鑰交換部分的keyexCHangealgoritHm參數(shù)迫使客戶端相信服務(wù)器是對(duì)短暫的rsa密鑰參數(shù)簽的名，而實(shí)際上，服務(wù)器是對(duì)短暫的diffie—Hellman密鑰參數(shù)簽的名。協(xié)議的初始階段，即在客戶端與服務(wù)器的握手信息中，客戶端首先向服務(wù)器發(fā)送rsa信息，該信息被攻擊者截獲篡改成包含短暫diffie—Hellman的rsa信息，并發(fā)往服務(wù)器。這樣，服務(wù)器就會(huì)接收到含有短暫diffie—Hellman的rsa信息。在服務(wù)器發(fā)給客戶端的應(yīng)答中包含對(duì)短暫diffie—Hell—man的rsa信息的確認(rèn)。同理，該確認(rèn)被攻擊者截獲并被篡改成對(duì)rsa信息的確認(rèn)，篡改后的確認(rèn)被攻擊者發(fā)往客戶端。此時(shí)，攻擊者就完成了對(duì)客戶端和服務(wù)器握手信息的篡改。在協(xié)議的服務(wù)器密鑰交換階段，服務(wù)器按照先前協(xié)商好的向客戶端發(fā)送含有生成diffie—Hellman密鑰的參數(shù)，這些參數(shù)被攻擊者截獲并將其中的diffie—Hellman替換成rsa，再將之發(fā)給客戶端。在協(xié)議的客戶端密鑰交換期間，客戶端利用服務(wù)器發(fā)給它的公共密鑰g對(duì)其產(chǎn)生的預(yù)主密鑰k進(jìn)行加密，即kgmodp，并將之發(fā)往服務(wù)器。該加密信息被攻擊者截獲并篡改成gxmodp發(fā)給服務(wù)器。在此情況下，攻擊者利用歐幾里得擴(kuò)展算法可以求得公共密鑰g的逆元g—1，由此通過模指數(shù)運(yùn)算（kg）g—1modp求得預(yù)主密鑰k；同樣，由于攻擊者擁有服務(wù)器發(fā)給它的參數(shù)Y，它自己生成的gx，因此可以計(jì)算出預(yù)主密鑰Y×gxmodp，即gy×gxmodp＝gxymodp。這樣，攻擊者就同時(shí)擁有了預(yù)主密鑰k和gxy。到此，攻擊者就可以分別利用k和gxy生成協(xié)議下一階段所需的對(duì)稱加密算法的密鑰，換言之，客戶端與服務(wù)器的加密通信對(duì)于攻擊者來說就是透明的了。（3）版本回退漏洞［8］。在ssl3．0協(xié)議中，本文只針對(duì)rsa的密鑰交換算法進(jìn)行了防版本回退攻擊，但對(duì)于非rsa密鑰交換算法的版本回退攻擊沒有考慮。攻擊者利用ClientHello＿2．0恢復(fù)一個(gè)由Cli—entHello＿3．0創(chuàng)建的會(huì)話。這樣，攻擊者就可以利用ssl2．0中的漏洞進(jìn)行攻擊了。攻擊過程如下所示：在圖6中，客戶端和服務(wù)器分別用自己的私鑰x、y生成公鑰gx、gy，并將各自的公鑰傳給對(duì)方。攻擊者將兩者的公鑰截獲，并利用自己的私鑰x′、y′偽造公鑰gx′、gy′。攻擊者將gy′傳給客戶端，將gx′傳給服務(wù)器。對(duì)于客戶端來說，由于不認(rèn)證攻擊者的身份，誤以為gy′是服務(wù)器傳來的；同理，對(duì)于服務(wù)器來說，誤以為gx′是客戶端傳來的。接著，客戶端和服務(wù)器分別生成密鑰gxy′和gx′y，攻擊者同樣生成密鑰gxy′和gx′y。這樣，客戶端和服務(wù)器在不知道攻擊者擁有各自的密鑰的情況下，利用協(xié)商好的HasH函數(shù)md5和sHa—1生成主密鑰，同樣攻擊者也生成相應(yīng)的主密鑰。由此，客戶端和服務(wù)器相互交換的信息對(duì)于攻擊者來說就是透明的了，不具備機(jī)密性了。

4結(jié)束語

互聯(lián)網(wǎng)存在近二十年了，已成為居家度日的必需品。Web安全協(xié)議ssl為使用互聯(lián)網(wǎng)的用戶進(jìn)行安全郵箱通信提供了重要而可靠的保障。本文針對(duì)ssl協(xié)議的握手協(xié)議部分進(jìn)行了詳盡的闡述，對(duì)其安全性作了一定的分析，給出了理論上在的三個(gè)邏輯漏洞的詳盡描述，并且經(jīng)過測(cè)試驗(yàn)證，指出了ssl協(xié)議存在＊＊＊模式漏洞。

作者：鐘軍吳雪陽江一民段光明單位：78046部隊(duì)