網(wǎng)絡(luò)安全協(xié)議課程設(shè)計--ssl協(xié)議的安全性研究

1、<p>　　SSL協(xié)議的安全性研究</p><p><b>　　1 引言</b></p><p>　　隨著計算機網(wǎng)絡(luò)技術(shù)的飛速發(fā)展，信息時代的人們對Internet的依賴性越來越大。當今時代，電子商務(wù)和電子政務(wù)的應(yīng)用越來越廣泛，然而網(wǎng)絡(luò)安全問題嚴重束縛了計算機網(wǎng)絡(luò)的進一步應(yīng)用。安全套接層SSL(Secure Sockets Layer)協(xié)議是由Netscap

2、e公司設(shè)計開發(fā)的安全協(xié)議，主要用于加強應(yīng)用程序之間的數(shù)據(jù)的安全性。SSL協(xié)議是基于Web應(yīng)用的安全協(xié)議，它采用了RSA算法、RC4—128、RC一128、三重DES算法和MD5等加密技術(shù)實現(xiàn)兩個應(yīng)用層之間的機密性、可靠性和數(shù)據(jù)完整性，并采用X．509數(shù)字證書實現(xiàn)鑒別，其加密的目的是建立一個安全的通訊通道，而且該通道可在服務(wù)器和客戶機兩端同時實現(xiàn)支持。</p><p>　　2 SSL協(xié)議簡述及相關(guān)概念</p&

3、gt;<p>　　SSL協(xié)議用來建立一個在客戶和服務(wù)器之間安全的TCP連接，尤其可被用來認證服務(wù)器，可選地認證客戶，執(zhí)行密鑰交換，提供消息認證，而且還可以完成在TCP協(xié)議之上的任意應(yīng)用協(xié)議數(shù)據(jù)的完整性和隱蔽性服務(wù)。SSL為在Internet上安全地傳送數(shù)據(jù)提供了一介加密通道，建立一個安全連接，主要實現(xiàn)以下工作：加密網(wǎng)絡(luò)上客戶端和服務(wù)器相互發(fā)送的信息；驗證信息在傳送過程是否安全完整：運用非對稱密鑰算法驗證服務(wù)器；驗證客戶身份

4、；交換應(yīng)用層數(shù)據(jù)。</p><p>　　2.1 SSL---安全套接層協(xié)議。</p><p>　　是由Netscape設(shè)計的一種開放性協(xié)議，它提供了一種介于應(yīng)用層和傳輸層之間的數(shù)據(jù)安全套接層協(xié)議機制。SSL位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，為TCP/IP連接提供數(shù)據(jù)加密、服務(wù)器認證、消息完整性以及可選的客戶機認證。其目的是為客戶端（瀏覽器）到服務(wù)端之間的信息傳輸構(gòu)建一個加密通道，此

5、協(xié)議是與操作系統(tǒng)和Web服務(wù)器無關(guān)的。</p><p>　　2.2 SSL協(xié)議可分兩層：</p><p>　　2.2.1 SSL記錄協(xié)議：</p><p>　　它建立在可靠的傳輸協(xié)議（如TCP）之上，位于SSL協(xié)議的底層，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。在SSL中，所有數(shù)據(jù)被封裝在記錄中，SSL握手協(xié)議中的報文，要求必須放在一個SSL記錄協(xié)議層的

6、記錄里，但應(yīng)用層協(xié)議的報文，允許占用多個SSL記錄來傳送</p><p>　　(1) SSL記錄頭格式</p><p>　　SSL記錄頭可以是2個或3個字節(jié)長的編碼。SSL記錄頭包含的信息有記錄頭的長度、記錄數(shù)據(jù)的長度，以及記錄數(shù)據(jù)中是否有填充數(shù)據(jù)，其中填充數(shù)據(jù)是在使用塊加密（blocken-cryption）算法時，填充實際數(shù)據(jù)，使其長度恰好是塊的整數(shù)倍。最高位為1時，不含有填充數(shù)據(jù)，記

7、錄頭的長度為2個字節(jié)，記錄數(shù)據(jù)的最大長度為32767個字節(jié)；最高位為0時，含有填充數(shù)據(jù)，記錄頭的長度為3個字節(jié)，記錄數(shù)據(jù)的最大長度為16383個字節(jié)。</p><p>　　SSL記錄層結(jié)構(gòu)如圖1所示。</p><p>　　圖1 SSL記錄層結(jié)構(gòu)</p><p>　　當數(shù)據(jù)頭長度是3個字節(jié)時，次高位有特殊的含義。次高位為1時，表示所傳輸?shù)挠涗浭瞧胀ǖ臄?shù)據(jù)記錄；次高位

8、為0時，表示所傳輸?shù)挠涗浭前踩瞻子涗洠ū槐Ａ粲糜趯韰f(xié)議的擴展）。</p><p>　　記錄頭中數(shù)據(jù)長度編碼不包括數(shù)據(jù)頭所占用的字節(jié)長度。記錄頭長度為2個字節(jié)時，記錄長度的計算公式為：記錄長度=（（Byte[0]&0x7f）<<8）|Byte[1]。其中Byte[0]、Byte[1]分別表示傳輸?shù)牡谝粋€、第二個字節(jié)。</p><p>　　記錄頭長度為3個字節(jié)時，記錄長

9、度的計算公式是：記錄長度=（（Byte[0]&0x3f<<8））</p><p>　　Byte[1]。其中Byte[0]、Byte[1]的含義同上。判斷是否是安全空白記錄的計算公式是：（Byte[0]&0x40）！=0。填充數(shù)據(jù)的長度為傳輸?shù)牡谌齻€字節(jié)。</p><p>　　(2) SSL記錄數(shù)據(jù)格式</p><p>　　SSL記錄數(shù)據(jù)部

10、分有3個分量：MAC-DATA、ACTUAL-DATA和PADDING-DATA。</p><p>　　MAC數(shù)據(jù)用于數(shù)據(jù)完整性檢查。計算MAC所用的散列函數(shù)由握手協(xié)議中的CIPHER-CHOICE消息確定。若使用MD2和MD5算法，則MAC數(shù)據(jù)長度是16個字節(jié)。MAC的計算公式為：MAC數(shù)據(jù)=Hash[密鑰, 實際數(shù)據(jù), 填充數(shù)據(jù), 序號]。</p><p>　　當會話的客戶端發(fā)送數(shù)據(jù)時

11、，密鑰是客戶的寫密鑰（服務(wù)器用讀密鑰來驗證MAC數(shù)據(jù)）；而當會話的客戶端接收數(shù)據(jù)時，密鑰是客戶的讀密鑰（服務(wù)器用寫密鑰來產(chǎn)生MAC數(shù)據(jù)）。序號是一個可以被發(fā)送和接收雙方遞增的計數(shù)器，每個通信方向都會建立一對計數(shù)器，分別被發(fā)送者和接收者擁有。計數(shù)器有32位，計數(shù)值循環(huán)使用，每發(fā)送一個記錄，計數(shù)值遞增一次，序號的初始值為0。</p><p>　　ACTUAL-DATA是被傳送的應(yīng)用數(shù)據(jù)，PADDING-DATA是當采

12、用分組碼時所需要的填充數(shù)據(jù)，在明文傳送下只有第二項。</p><p>　　(3) 記錄協(xié)議的作用</p><p>　　記錄協(xié)議層封裝了高層協(xié)議的數(shù)據(jù)，協(xié)議數(shù)據(jù)采用SSL握手協(xié)議中協(xié)商好的加密算法及MAC算法來保護。記錄協(xié)議傳送的數(shù)據(jù)包括一個序列號，這樣就可以檢測消息的丟失、改動或重放。如果協(xié)商好了壓縮算法，那么SSL記錄協(xié)議還可以執(zhí)行壓縮功能。</p><p>　　

13、SSL V3版的高層由記錄傳遞的消息組成，這包括改變密碼規(guī)范協(xié)議、警報協(xié)議和握手協(xié)議。改變密碼規(guī)范協(xié)議指明對使用的密碼規(guī)范的改變，協(xié)議中還包括了一個用當前密碼規(guī)范加密的單獨消息?？蛻艉头?wù)器都要發(fā)送改變密碼規(guī)范消息來表明它們準備使用一個新的密碼規(guī)范和密鑰。警報協(xié)議傳送與事件相關(guān)的消息，包括事件嚴重性及事件描述。這里的事件主要是指錯誤情形，如錯誤的MAC碼、證書過期或是非法參數(shù)。警報協(xié)議也用于共享有關(guān)預(yù)計連接終止的信息。</p>

14、;<p>　　2.2.2 SSL握手協(xié)議：</p><p>　　SSL中最復(fù)雜的部分，它建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，在會話狀態(tài)下產(chǎn)生所需要的各種安全參數(shù)，通訊雙方進行身份認證、協(xié)商加密算法、交換加密密鑰等。</p><p>　　2.3 SSL協(xié)議的作用</p><p>　　SSL是提供Internet上的通信隱私性的安全協(xié)議。

15、該協(xié)議允許客戶端/服務(wù)器應(yīng)用之間進行防竊聽、防消息篡改及防消息偽造的安全的通信。TCP/IP是整個Internet數(shù)據(jù)傳輸和通信所使用的最基本的控制協(xié)議，在它之上還有HTTP（Hypertext Transfer Protocol）、LDAP（Lightweight Directory Access Protoco1）、IMAP（Internet Messaging Access Protocol）等應(yīng)用層傳輸協(xié)議。而SSL是位于TCP

16、/IP和各種應(yīng)用層協(xié)議之間的一種數(shù)據(jù)安全協(xié)議（如圖2所示）。SSL協(xié)議可以有效地避免網(wǎng)上信息的偷聽、篡改及信息的偽造。</p><p>　　圖2 SSL協(xié)議的位置</p><p>　　SSL標準的關(guān)鍵是要解決以下幾個問題。</p><p>　　（1）客戶對服務(wù)器的身份確認：SSL服務(wù)器允許客戶的瀏覽器使用標準的公鑰加密技術(shù)和一些可靠的認證中心（CA）的證書，來確認

17、服務(wù)器的合法性（檢驗服務(wù)器的證書和ID的合法性）。對于用戶服務(wù)器身份的確認與否是非常重要的，因為客戶可能向服務(wù)器發(fā)送自己的信用卡密碼。</p><p>　　（2）服務(wù)器對客戶的身份確認：允許SSL服務(wù)器確認客戶的身份，SSL協(xié)議允許客戶服務(wù)器的軟件通過公鑰技術(shù)和可信賴的證書來確認客戶的身份（客戶的證書）。對于服務(wù)器客戶身份的確認與否是非常重要的，因為網(wǎng)上銀行可能要向客戶發(fā)送機密的金融信息。</p>

18、<p>　?。?）建立起服務(wù)器和客戶之間安全的數(shù)據(jù)通道：SSL要求客戶和服務(wù)器之間所有的發(fā)送數(shù)據(jù)都被發(fā)送端加密，所有的接收數(shù)據(jù)都被接收端解密，這樣才能提供一個高水平的安全保證。同時SSL協(xié)議會在傳輸過程中檢查數(shù)據(jù)是否被中途修改。</p><p>　　2.4 SSL協(xié)議的目標</p><p>　　按它們的優(yōu)先級，SSL協(xié)議的目標如下。</p><p>　?。?/p>

19、1）在通信雙方之間利用加密的SSL消息建立安全的連接。</p><p>　?。?）互操作性。通信雙方的程序是獨立的，即一方可以在不知道對方程序編碼的情況下，利用SSL成功地交換加密參數(shù)。</p><p>　　注意：并不是所有的SSL實例（甚至在同一應(yīng)用程序內(nèi)）都可以成功地連接。例如，如果服務(wù)器支持一特定的硬件令牌（token），而客戶端不能訪問此令牌，則連接不會成功。</p>

20、<p>　　（3）可擴展性。SSL尋求提供一種框架結(jié)構(gòu)，在此框架結(jié)構(gòu)中，在不對協(xié)議進行大的修改的情況下，可以在必要時加入新的公鑰算法和單鑰算法。這樣做還可以實現(xiàn)兩個子目標：</p><p>　　— 避免產(chǎn)生新協(xié)議的需要，因而進一步避免了產(chǎn)生新的不足的可能性；</p><p>　　— 避免了實現(xiàn)一完整的安全協(xié)議的需要。</p><p>　　相對于有效性加密

21、操作，尤其是公鑰加密，對CPU來說是一種很耗時的事，因此SSL協(xié)議引入一個可選的對話緩存（Cache）來減少從頭開始的連接數(shù)目。同時，它還注意減少網(wǎng)絡(luò)的活動。</p><p>　　3 SSL協(xié)議工作原理</p><p>　　SSL協(xié)議用來建立一個在客戶和服務(wù)器之間安全的TCP連接，尤其可被用來認證服務(wù)器，可選地認證客戶，執(zhí)行密鑰交換，提供消息認證，而且還可以完成在TCP協(xié)議之上的任意應(yīng)用協(xié)

22、議數(shù)據(jù)的完整性和隱蔽性服務(wù)。SSL為在Internet上安全地傳送數(shù)據(jù)提供了一介加密通道，建立一個安全連接，主要實現(xiàn)以下工作：加密網(wǎng)絡(luò)上客戶端和服務(wù)器相互發(fā)送的信息；驗證信息在傳送過程是否安全完整：運用非對稱密鑰算法驗證服務(wù)器；驗證客戶身份；交換應(yīng)用層數(shù)據(jù)?；静襟E如下：</p><p>　　（1）客戶端服務(wù)器發(fā)送一個開始信息以便開始一個新的會話連接，協(xié)商傳送加密算法。例如：告知服務(wù)端，客戶端自己的對稱加密算法有

23、DES、RC5，自己的密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。</p><p>　?。?）服務(wù)器根據(jù)客戶的信息確定是否需要生成新的主密鑰，如需要則服務(wù)器在響應(yīng)客戶的信息時將包含生成主密鑰所需的信息，并發(fā)送服務(wù)器數(shù)字證書。例如：告知客戶端，服務(wù)器就使用DES-RSA-MD5這對組合進行通訊，為了證明“我”確實是服務(wù)器，現(xiàn)在就發(fā)送“我”的數(shù)字證書給客戶端，以便于驗證服務(wù)器的身份。</p>

24、<p>　?。?）客戶端根據(jù)收到的服務(wù)器響應(yīng)信息，檢查服務(wù)器的數(shù)字證書是否正確，通過CA機構(gòu)頒發(fā)的證書及CA的公鑰對服務(wù)器證書進行解密，獲得服務(wù)器公鑰，然后產(chǎn)生一個主密鑰，并用服務(wù)器的公鑰加密后傳給服務(wù)器。例如：服務(wù)器，“我”已經(jīng)確認了你的身份，現(xiàn)在把我們本次通訊中的密鑰發(fā)送給你。</p><p>　　（4）服務(wù)器使用自己的私鑰解密該消息，然后生成會話密鑰，接著使用服務(wù)器公鑰加密，再發(fā)送給客戶端。這樣，

25、服務(wù)器和客戶端都擁有了會話密鑰。例如：客戶端，“我”已經(jīng)獲取了密鑰，我們可以開始通信了。</p><p>　　服務(wù)器和客戶端使用會話密鑰來加密和解密傳輸?shù)臄?shù)據(jù)。它們之問的數(shù)據(jù)傳輸?shù)氖菍ΨQ加密。</p><p>　　一般情況下，當客戶端是保密信息的傳遞者時，不需要數(shù)字證書驗證自己身份的真實性，如電子銀行的應(yīng)用，客戶需要將自己的賬號和密碼發(fā)送給銀行，因此銀行的服務(wù)器需要安裝數(shù)字證書來表明自己身

26、份的有效性。但在某些B2B應(yīng)用中，服務(wù)器端也需要對客戶端的身份進行驗證，這時客戶端也需要安裝數(shù)字證書以保證通訊時服務(wù)器可以辨別出客戶端的身份，驗證過程類似于服務(wù)器身份的驗證過程。</p><p><b>　　4 SSL握手過程</b></p><p>　　SSL用公鑰加密算法使服務(wù)器端在客戶端得到驗證，并傳遞對稱密鑰。然后再用對稱密鑰來更快速地加密、解密數(shù)據(jù)。<

27、/p><p><b>　　以下為具體過程：</b></p><p>　　（1）客戶端向Server端發(fā)送客戶端SSL版本號、加密算法設(shè)置、隨機產(chǎn)生的數(shù)據(jù)和其他服務(wù)器需要用于根客戶端通信的數(shù)據(jù)。</p><p>　　（2）服務(wù)器向客戶端發(fā)送服務(wù)器的SSL版本號、加密算法設(shè)置、隨機產(chǎn)生的數(shù)據(jù)和其他客戶端需要用于根服務(wù)器通信的數(shù)據(jù)。另外，服務(wù)器還有發(fā)送自

28、己的證書，如果客戶端正在請求需要認證的信息，那么服務(wù)器同時也要請求獲得客戶端的證書。</p><p>　　（3）客戶端用服務(wù)器發(fā)送的信息驗證服務(wù)器身份。如果認證不成功，用戶就將得到一個警告，然后加密數(shù)據(jù)連接將無法建立。如果成功，則繼續(xù)下一步。</p><p>　　（4）用戶用握手過程至今產(chǎn)生的所有數(shù)據(jù)，創(chuàng)建連接所用的密鑰，用服務(wù)器的公鑰加密，傳送給服務(wù)器。</p><p

29、>　?。?）如果服務(wù)器也請求客戶端驗證，那么客戶端將對另外一份不同于上次用于建立加密連接使用的數(shù)據(jù)進行簽名。在這種情況下，客戶端會把這次產(chǎn)生的加密數(shù)據(jù)和自己的證書同時傳送給服務(wù)器用來產(chǎn)生Premaster Secret。</p><p>　?。?）如果服務(wù)器也請求客戶端驗證，服務(wù)器將試圖驗證客戶端身份。如果客戶端不能獲得認證，連接將被中止。如果被成功認證，服務(wù)器用自己的私鑰加密建立連接所用的密鑰，然后執(zhí)行一

30、系列步驟產(chǎn)生主密鑰。</p><p>　?。?）服務(wù)器和客戶端同時產(chǎn)生會話密鑰，之后的所用數(shù)據(jù)傳輸都用對稱密鑰算法來交流數(shù)據(jù)。</p><p>　　（8）客戶端向服務(wù)器發(fā)送信息說明以后的所有信息都將用會話密鑰加密。至此，它會傳送一個單獨的信息標示客戶端的握手部分已經(jīng)宣告結(jié)束。</p><p>　　（9）服務(wù)器也向客戶端發(fā)送信息說明以后的所用信息都將用會話密鑰加密。至

31、此，它會傳送一個單獨的信息標示服務(wù)器端得握手部分已經(jīng)宣告結(jié)束。</p><p>　?。?0）SSL握手過程結(jié)束，一個SSL數(shù)據(jù)傳送過程建立。客戶端和服務(wù)器開始用會話密鑰加密、解密雙方交互的所用數(shù)據(jù)。</p><p>　　5 SSL的安全威脅及解決方案</p><p>　　SSL協(xié)議在服務(wù)器與客戶之間建立了一條安全通道，保證了在互聯(lián)網(wǎng)上通信的保密性，但它也不是絕對安全

32、的，SSL協(xié)議存在一定的缺陷和漏洞。</p><p>　　5.1通信業(yè)務(wù)流攻擊</p><p><b>　　5.1.1攻擊原理</b></p><p>　　通信業(yè)務(wù)流攻擊試圖通過檢查未保護的包的某些域或會話屬性，發(fā)現(xiàn)有價值的信息。例如，通過檢查沒有經(jīng)過加密的IP包的源地址、目標地址、TCP端口等內(nèi)容，能夠獲得有關(guān)通信雙方的IP地址、正在使用的網(wǎng)

33、絡(luò)服務(wù)等信息，在某些特定情況下，甚至可以獲得有關(guān)商業(yè)或個人關(guān)系方面的信息，當然這些信息是有價值的。而在SSL協(xié)議中記錄頭中如記錄長度等信息沒有被保護，這是潛在的隱患。攻擊者通過檢查通信業(yè)務(wù)流中密文信息的長度，有可能發(fā)現(xiàn)Web通信中URL請求的相關(guān)信息，當瀏覽器連接到Web服務(wù)器時，瀏覽器發(fā)送的包含URL的G盯請求數(shù)據(jù)包是加密的，Web服務(wù)器返回的Web頁也是加密的，但是通信業(yè)務(wù)流攻擊，攻擊者可以得到Web服務(wù)器的IP地址、URL請求的長

34、度和返回的Web頁面長度等信息，這些信息足以使攻擊者發(fā)現(xiàn)用戶訪問的是什么Web頁面。因為，目前高級的Web搜索引擎技術(shù)能夠在可以公開訪問的Web服務(wù)器上，搜索到給定URL長度和Web頁面長度的頁面。這種攻擊能夠成立的原因是密文長度揭露了明文信息的長度。由于SSL協(xié)議只對分組密碼算法有填充機制，而對于流密碼算法該協(xié)議是不支持的，所以這種潛在的可能性攻擊還需要引起我們的重</p><p><b>　　5.1

35、.2解決策略</b></p><p>　　該攻擊僅僅是描述了一種潛在的可能性，能夠攻擊成功還需要許多前提條件。但是，這種潛在的可能性應(yīng)當引起注意，在具體應(yīng)用過程中盡量避免。SSL協(xié)議無法抵抗通信業(yè)務(wù)流攻擊，而且以SSL協(xié)議為基礎(chǔ)的傳輸層安全協(xié)議TL S協(xié)議仍然不能抵抗這種攻擊，這是由于協(xié)議的設(shè)計目標和其所處的網(wǎng)絡(luò)層次結(jié)構(gòu)決定的。在TL S協(xié)議中也沒有作出改進，只是在文檔中強調(diào)了協(xié)議的設(shè)計目標和這種攻擊

36、的危險性，告誡協(xié)議的應(yīng)用者不能在未保護的通信業(yè)務(wù)流中暴露機密信息。對于通信業(yè)務(wù)流攻擊，只能通過應(yīng)用者的謹慎，盡量避免泄漏有關(guān)重要信息。</p><p>　　5.2密鑰交換算法欺騙</p><p><b>　　5.2.1攻擊原理</b></p><p>　　在有些情況下，服務(wù)器用Server Key exchange消息來交換密鑰，并用自己的長期

37、有效的證書為臨時的公開參數(shù)簽名，同時發(fā)給客戶，客戶使用這些公開參數(shù)和服務(wù)器交換密鑰，獲得共享的主密鑰。SSL協(xié)議規(guī)定可以使用RSA算法和Diffie-Hellman等多種密鑰交換算法，但KeyExchange Algorithm這個域并不包含在服務(wù)器對公開參數(shù)的簽名內(nèi)容中，這樣攻擊者可以濫用服務(wù)器對DH參數(shù)的簽名來欺騙客戶，使之認為服務(wù)器發(fā)送了對RSA參數(shù)的簽名，攻擊者使用Cipher Suite回轉(zhuǎn)攻擊(在交換finished消息之前

38、攻擊者就能夠通過后繼的攻擊獲得所有秘密，所以能夠偽造finished消息，則該攻擊是能夠獲得成功的)，使服務(wù)器使用臨時的DH密鑰交換，而客戶使用臨時的RSA密鑰交換，這樣，DH的素數(shù)模p(dh—p)和生成因子g(dh—g)將被客戶理解為RsA的模p(rsa—modulus)和指數(shù)g(rsa—exponent)。那么，客戶將使用假的RSA參數(shù)加密主密鑰發(fā)送給服務(wù)器。攻擊者截獲RsA加密的值gkmod p，因為p是素數(shù)，所以可以容易地求出其

39、第g個根，從而恢復(fù)出主密鑰的P</p><p><b>　　5.2.2解決策略</b></p><p>　　這種安全缺陷也可以通過協(xié)議實現(xiàn)者的特殊處理加以避免，協(xié)議應(yīng)用者需要在接收到key exchange消息時仔細檢查公開參數(shù)域的長度，就能夠區(qū)分所使用的密鑰交換算法，如DES算法密鑰長度為40bit從而避免這種攻擊。</p><p>　　5.

40、3 Change Cipher Spec消息丟棄</p><p><b>　　5.3.1攻擊原理</b></p><p>　　SSL握手協(xié)議中有一個小的漏洞，那就是在finished消息中沒有對change cipher spec消息的認證保護。從而存在一種潛在的攻擊方法——丟棄change cipher spec消息。在正常的通信情況下，雙方的通信流程如下：<

41、/p><p>　　(1)C->S：[change cipher spec]</p><p>　　(2)C->S：[finished]{a}k</p><p>　　(3)S->C：[change cipher spec]</p><p>　　(4)S->C：[finished]{a}k</p><p>

42、;　　(5)C->S：{m}k</p><p>　　但存在一種特殊的情況，在這種情況下，中間人M(man—in—the—middle—attack)采取change cipher spec消息丟失攻擊，這種攻擊的前提是當前的Cipher Suite不作MAC保護；未決的Cipher Suite不作加密，作MAC保護，那么攻擊的消息流如下：</p><p>　　(1)C->M：[

43、Change Cipher Spec]</p><p>　　(2)C->M：[finished]{a}k</p><p>　　(3)M->S：[finished]a</p><p>　　(4)S—>M：[change cipher spec]</p><p>　　(5)S—>M：[finished]a</p>

44、;<p>　　(6)M->C：[finished]a</p><p>　　(7)C->M：{m}k</p><p><b>　　(8)M->S：m</b></p><p>　　其中{*}k表示記錄層協(xié)議對數(shù)據(jù)進行加密保護；m表示明文的應(yīng)用數(shù)據(jù)；n表示finished消息中的認證碼，是對所有握手消息進行MAC計算結(jié)

45、果(但不包括Change Cipher Spec消息的認證)。從以上過程可以看出，在接收到Change Cipher Spec消息之前，當前的Cipher Suite不加密，不作Mac保護，直到收到Change Cipher spec消息之后，記錄層才開始對通信數(shù)據(jù)進行加密和完整性保護。假如只對密碼族進行認證而從不加密，這樣中間人攻擊者將竊取并刪除Change Cipher Spec消息，致使通信雙方將不再更新當前的密碼族(Cipher

46、 Suite)，即不再對傳遞的數(shù)據(jù)作MAC認證和加密。由于商定的密碼族不起作用，這樣協(xié)議失去了對數(shù)據(jù)的認證能力，從而中間人攻擊者在通信雙方不知道的情況下，可以任意修改會話數(shù)據(jù)。</p><p><b>　　5.3.2解決策略</b></p><p>　　將Change Cipher Spec假如到Finished消息的消息認證計算中，這樣才符合認證協(xié)議的上下文原則。當

47、然，也可以不修改協(xié)議的基本框架，在發(fā)送Finished消息之前要求收到Change Cipher Spec的消息，否則引起協(xié)議的致命錯誤并會中斷連接，這實際上是協(xié)議實現(xiàn)者對SSL協(xié)議缺陷的彌補工作。</p><p>　　5.4 證書攻擊和竊取</p><p><b>　　5.4.1攻擊原理</b></p><p>　　公共CA機構(gòu)并不總是很可靠

48、的，因為對于用戶的證書，公共CA機構(gòu)可能不像對網(wǎng)站數(shù)字證書那樣重視和關(guān)心其準確性。由于微軟公司的¨S服務(wù)器提供了“客戶端證書映像”功能，用于將客戶端提交證書的名字映射到NT系統(tǒng)的用戶帳號，在這種情況下，攻擊者就有可能獲得該主機的系統(tǒng)管理員的權(quán)限；當然，如果攻擊者不能利用上面的非法的證書突破服務(wù)器的話，他們還可以嘗試運用暴力攻擊獲取訪問的權(quán)限，運用暴力攻擊客戶端認證的方法是：攻擊者編輯一個可能的用戶名字列表，然后為每一個名字向C

49、A機構(gòu)申請證書。每一個證書都用于嘗試獲取訪問權(quán)限。用戶名的選擇越好，其中一個證書被認可的可能性就越高。暴力攻擊證書的方便之處在于它僅需要猜測～個有效的用戶名，而不是猜測用戶名和口令。</p><p>　　攻擊者還可能竊取有效的證書及相應(yīng)的私有密鑰，其最簡單的方法是特洛依木馬病毒，這種攻擊幾乎可使客戶端證書形同虛設(shè)，它攻擊的是證書的一個根本性弱點：私有密鑰——整個安全系統(tǒng)的核心——經(jīng)常保存在不安全的地方，對付這種攻

50、擊的唯一有效方法是將證書保存到智能卡或令牌之類的設(shè)備中。</p><p>　　圖3 客戶端SSL通信安全代理工作原理示意圖</p><p><b>　　5.4.2解決策略</b></p><p>　　證書的安全可以采用IDs(Intrusion Detection System)，它是一種用于監(jiān)測攻擊服務(wù)器企圖的技術(shù)和方法。典型的IDS監(jiān)視到網(wǎng)

51、絡(luò)信息與保存在數(shù)據(jù)庫中的已知攻擊“特征”或方法進行比較，如果發(fā)現(xiàn)攻擊，IDS可以提醒系統(tǒng)管理員切斷連接或甚至實施反攻擊等。但是，如果網(wǎng)絡(luò)通信是加密的，IDS將無法監(jiān)視攻擊者，而且反而可能會使攻擊者更為輕松的實施攻擊。解決的方法是通過Proxy代理服務(wù)器的SSL，可以在一個SSL proxy代理服務(wù)器程序上使用這項資料審查技術(shù)。SSL proxy是一個連接在80端口上接受純文字的HTTP通信請求的軟件，它會將這些請求通過經(jīng)由SSL加密過的

52、連接，轉(zhuǎn)寄到目標網(wǎng)站。在連接端口80開一個聽取S0cket(偵聽)，通過0pen SSL0．9．6指令，將所有進入這個Proxy的數(shù)據(jù)傳送出去。通過這個SSL Pro)(y機制，只要將安全掃描軟件指向Proxy的IP地址，就可以用來審查SSL服務(wù)器，從而滿足信息傳輸安全的需求，其使用proxy代理服務(wù)器的工作原理如圖3。</p><p>　　5.5 SSL不能提供交易的不可否認性</p><p

53、>　　SSL協(xié)議是基于Web應(yīng)用的安全協(xié)議，它只能提供安全認證，SSL鏈路上的數(shù)據(jù)完整性和保密性。對于電子商務(wù)的交易應(yīng)用層的信息不進行數(shù)據(jù)簽名，因此，不能提供交易的不可否認性，這是SSL在電子商務(wù)中使用的最大缺欠</p><p>　　5.6 密鑰管理問題 客戶機和服務(wù)器在連接初期互相發(fā)送自己能支持的加密算法時，以明文返回選定的加密算法和主密鑰，主密鑰前40位不加密，其余位加密，此時可能會被攻擊者修改

54、為強度最弱的加密算法，導(dǎo)致以后傳輸?shù)募用軘?shù)據(jù)包被攻擊者破解。另外，所有的會話密鑰中都將生成主密鑰master-key，實際的密鑰并不是主密鑰，而是由它生成的兩個密鑰client-write-key (server -read-key)和client - read-key( server-write-key)，并且當客戶機和服務(wù)器再次握手時，不再協(xié)商加密算法和主密鑰，因此握手協(xié)議的安全完全依賴于對主密鑰的保護，如果主密鑰管理不妥被泄露，則

55、通訊傳輸中的加密數(shù)據(jù)包極可能被破譯。</p><p>　　5.7 加密算法的強度限制</p><p>　　通過互聯(lián)網(wǎng)傳輸敏感數(shù)據(jù)的一個問題是傳輸過程會經(jīng)過許多中間環(huán)節(jié)，這一路由過程是所有互聯(lián)網(wǎng)傳輸?shù)幕A(chǔ),而在路由線路上的任何一臺計算機都可能完全獲得傳輸?shù)男畔ⅲ@樣就使得別人有可能截獲并破譯你的秘密信息。美國政府規(guī)定，加密技術(shù)屬于軍用品受軍火國際貿(mào)易法規(guī)的制約，其產(chǎn)品出口必須取得出口許可證。

56、因此密鑰長度超過512bit的RSA算法不能用于SSL的密鑰交換算法，密鑰長度超過40bit的對稱加密算法如RC4，DES等不能用于SSL的數(shù)據(jù)加密，故美國出口的SSL協(xié)議產(chǎn)品的加密算法的安全性不足，不能用于安全性要求高的網(wǎng)絡(luò)服務(wù)。</p><p>　　5.8 版本回滾攻擊</p><p>　　SSL 3.0不包含任何重大缺陷,通過SSL 2.0協(xié)議得到了一些改進,這就是為什么我們不希望一

57、個攻擊者嘗試版本回滾的攻擊。對于攻擊者使版本3.0的各部分回到2.0版本，是非常有用的基于SSL3.0的改進。這種攻擊只會發(fā)生在兩個3.0版本兼容使用的是2.0版情況下。這允許中間人讓客戶選擇一個較弱的cipher suite來進行攻擊。例如選擇DES對稱加密算法。如果發(fā)生這種情況,一個攻擊者可能暴力途徑獲得這兩個部分之間交換的數(shù)據(jù)。這個攻擊者也獲得如密碼和身份cookie等信息。不幸的是，如今，SSL2.0在服務(wù)器端依然是默認的。&l

58、t;/p><p>　　有一個主要預(yù)防的手段在SSL3.0上,但它留下了一些情況下成功進行版本回滾的攻擊。這種預(yù)防是向RSA填充位添加版本號。在任何敏感數(shù)據(jù)被發(fā)送之前，兩個使用2.0版本的被騙部分將檢測到錯誤。顯然，這僅適用于一個RSA已經(jīng)被選擇的情況下。如果攻擊者把字段替代為2.0版hello消息和Diffie-Hellman,攻擊也奏效。也可能在session回復(fù)期間獲得數(shù)據(jù)。因為某種原因服務(wù)器允許一個客戶端來恢復(fù)

59、一個3.0版本session到2.0 版本hello報文,因為它在恢復(fù)期,主密鑰沒有重新共享。因此沒有RSA填充檢測到錯誤的版本號。幸運的是,這些漏洞可以通過執(zhí)行禁用 3.0版本到2.0版本的恢復(fù)進行控制,并通過只允許RSA運行在2.0版本的兼容性模式。最好的行動當然是禁用2.0版本兼容性模式。</p><p><b>　　參考文獻:</b></p><p>　　[1

60、] 劉春榮. 基于SSL協(xié)議的電子商務(wù)安全性分析[J]. 信息與電腦. P10-12, 2010.3.</p><p>　　[2] 王偉. SSL、SET協(xié)議及其安全技術(shù)[J]. 鄭州航空工業(yè)管理學(xué)院學(xué)報(社會科學(xué)版). 23(1), P122-123, 2004.2.</p><p>　　[3] 蘇金國. SSL安全協(xié)議[J]. 上海微型計算機. 2001.1.</p>&

61、lt;p>　　[4] 戴英俠, 左英男, 許劍卓. SSL協(xié)議的安全缺陷與改進[J]. 中國科學(xué)院研究生院學(xué)報. 17(1),P86—92, 2004.2.</p><p>　　[5] 任靜，李濤. 客戶端SSL安全代理的設(shè)計與實現(xiàn)[J]. 計算機應(yīng)用研究. P80-81, 2003.6.</p><p>　　[6] 胡國華，袁樹杰. SSL協(xié)議安全缺陷分析[J].計算機系統(tǒng)應(yīng)用.