第一篇：什么是SSL安全協議

什么是SSL安全協議

SSL安全協議最初是由Netscape Communication公司設計開發的，又叫“安全套接層(Secure Sockets Layer)協議”，主要用于提高應用程序之間數據的安全系數。SSL協議的整個概念可以被總結為：一個保證任何安裝了安全套接字的客戶和服務器間事務安全的協議，它涉及所有TC/IP應用程序。

SSL安全協議主要提供三方面的服務：

用戶和服務器的合法性認證

認證用戶和服務器的合法性，使得它們能夠確信數據將被發送到正確的客戶機和服務器上。客戶機和服務器都是有各自的識別號，這些識別號由公開密鑰進行編號，為了驗證用戶是否合法，安全套接層協議要求在握手交換數據時進行數字認證，以此來確保用戶的合法性。

加密數據以隱藏被傳送的數據

安全套接層協議所采用的加密技術既有對稱密鑰技術，也有公開密鑰技術。在客戶機與服務器進行數據交換之前，交換SSL初始握手信息，在SSL握手情息中采用了各種加密技術對其加密，以保證其機密性和數據的完整性，并且用數字證書進行鑒別，這樣就可以防止非法用戶進行破譯。

保護數據的完整性

安全套接層協議采用Hash函數和機密共享的方法來提供信息的完整性服務，建立客戶機與服務器之間的安全通道，使所有經過安全套接層協議處理的業務在傳輸過程中能全部完整準確無誤地到達目的地。

安全套接層協議是一個保證計算機通信安全的協議，對通信對話過程進行安全保護，其實現過程主要經過如下幾個階段：

1.接通階段：客戶機通過網絡向服務器打招呼，服務器回應;

2.密碼交換階段：客戶機與服務器之間交換雙方認可的密碼，一般選用RSA密碼算法，也有的選用Diffie-Hellmanf和Fortezza-KEA密碼算法;

3.會談密碼階段：客戶機器與服務器間產生彼此交談的會談密碼;

4.檢驗階段：客戶機檢驗服務器取得的密碼;

5.客戶認證階段：服務器驗證客戶機的可信度;

6.結束階段：客戶機與服務器之間相互交換結束的信息。

當上述動作完成之后，兩者間的資料傳送就會加密，另外一方收到資料后，再將編碼資料還原。即使盜竊者在網絡上取得編碼后的資料，如果沒有原先編制的密碼算法，也不能獲得可讀的有用資料。

發送時信息用對稱密鑰加密，對稱密鑰用非對稱算法加密，再把兩個包綁在一起傳送過去。

接收的過程與發送正好相反，先打開有對稱密鑰的加密包，再用對稱密鑰解密。在電子商務交易過程中，由于有銀行參與，按照SSL協議，客戶的購買信息首先發往商家，商家再將信息轉發銀行，銀行驗證客戶信息的合法性后，通知商家付款成功，商家再通知客戶購買成功，并將商品寄送客戶。

本文由：ev ssl證書 http://verisign.itrus.com.cn/ 整理

第二篇：淺析電子商務安全協議SSL與SET

淺析電子商務安全協議SSL與SET

一、引言

電子商務融計算機技術、通信技術、網絡技術于一體，以Internet為基礎平臺，互動性、開放性、廣泛性為其顯著特點。由于其開放性與廣泛性，必然面臨各種安全風險，如信息泄露或被篡改、欺騙、抵賴等。所以，安全問題已成為發展可信賴電子商務環境的瓶頸。目前，眾多的安全技術都是通過安全協議來實施的。因此，簡潔、有效的安全協議對電子商務安全而言至關重要。現今，國際上主要通行的兩種安全協議：安全套接層協議SSL和安全電子交易協議SET，二者均是成熟和實用的安全協議，但是由于它們的設計目的不同，所以在應用上有很大的差別。

二、兩種電子商務安全協議介紹

（一）安全套接層協議SSL

SSL是網景(Netscape)公司提出的基于WEB應用的安全協議，其目的是在Internet基礎上提供的一種保證機密性的安全協議。它能使客戶端／服務器應用之間的通信不被攻擊者竊聽，并且始終對服務器進行認證，而且還可選擇對客戶端進行認證。

SSL協議是國際上最早應用于電子商務的一種網絡安全協議，主要用于提高應用程序之間的數據安全。它同時使用對稱加密算法和公鑰加密算法，前者在速度上比后者要快很多，但是后者可以實現更好的安全認證。一個SSL傳輸過程首先需要握手：用公鑰加密算法使服務器在客戶端得到認證，以后就可以使用雙方商議成功的對稱密鑰來更快速的加密、解密數據。

SSL協議要求建立在可靠的傳輸層協議(例如：TCP)之上。SSL協議的優勢在于它是與應用層協議獨立無關的。高層的應用層協議(例如：HTTP，FTP)能透明地建立于SSL協議之上。SSL協議在應用層協議通信之前就已經完成加密算法、通信密鑰的協商以及服務器認證工作。應用層協議所傳送的數據都會被加密，從而保證通信的機密性。對于電子商務應用來說，使用SSL可保證信息的真實性、完整性和保密性。SSL協議由SSL記錄協議和SSL握手協議兩部分組成。

1、SSL記錄協議

在SSL協議中，所有的傳輸數據都被封裝在記錄中。所有的SSL通信，包括握手消息、安全空白記錄和應用數據都使用SSL記錄協議。記錄協議允許服務器和客戶端相互認證并協商加密算法和密鑰，對所有發送和接收的數據進行分段、壓縮、認證、加密和完整性服務。

2、SSL握手協議

SSL握手協議包括建立在記錄協議之上的握手協議、警報協議、更改加密說明協議和應用數據協議等對會話和管理提供支持的子協議，其用于在通信雙方之間建立安全傳輸通道。握手過程一般分為4個階段：

(1)初始化邏輯連接，客戶端先發出ClientHello消息，服務器返回一個ServerHello消息，這兩個消息用來協商雙方的安全能力，包括協議版本、對稱加密算法、壓縮算法等。

(2)服務器發送數字證書(包含了服務器的公鑰等)和會話密鑰。如果服務器要求認證客戶端，則要發送CertificateRequest消息。最后服務器發送ServerHelloDone消息，表示hello階段結束，服務器等待客戶端的響應。

(3)如果服務器要求認證客戶端，則客戶端先發送Certificate消息，然后產生會話密鑰，并用服務器的公鑰加密，封裝在ClientKeyExchange消息中，如果客戶端發送了自己的數字證書，則再發送一個數字簽名CertificateVerify來對數字證書進行校驗。

(4)客戶端發送一個ChangeCipherspec消息，通知服務器以后發送的消息將采用先前協商好的安全參數加密，最后再發送一個加密后的Finished消息。服務器在收到上述兩個消息后，也發送自己的ChangeCipherspec消息和Finished消息。

至此，握手全部完成，雙方就可以開始傳輸應用數據了。

3、SSL提供的功能及局限性

SSL使用加密的辦法建立一個安全的傳輸通道,它可提供以下3種基本的安全服務功能：

(1)信息加密。客戶端和服務器之間的所有的應用數據使用在SSL握手過程中建立的密鑰和算法進行加密。這樣就防止了某些用戶通過使用IP packet sniffer等工具進行非法竊聽或者破譯。

(2)信息完整。SSL提供完整信息服務，以建立客戶端與服務器之間的安全通道，使所有經過SSL協議處理的業務能全部準確無誤地到達目的地。

(3)相互認證。客戶端和服務器都有各自的識別號，這些識別號由公開密鑰進行編號。為了認證用戶是否合法，SSL協議要求在握手交換數據前進行數字認證，來確保用戶的合法性。

SSL協議的局限性：首先，客戶的信息先到商家，讓商家閱讀，這樣，客戶資料的安全性就得不到保證；其次，SSL只能保證資料信息傳遞的安全，而傳遞過程是否有人截取就無法保證了。所以，SSL并沒有實現電子支付所要求的保密性、完整性，而且多方互相認證也是很困難的。此外，該協議最大的弱點是不能做數字簽名，因此不支持不可否認性。另外，它不能對商家進行認證，不能防止網上欺詐行為。

（二）安全電子交易協議SET

安全電子交易(Secure Electronic Transaction．簡稱SET)協議是由Visa和Master Card公司在1996年底開發的，主要為在網上在線交易時保證使用信用卡進行支付時的安全而設立的一個開放的協議，它是面向網上交易，針對利用信用卡進行支付而設計的電子支付規范。SET提供了消費者、商家和銀行之間的認證，確保交易的保密性、可靠性和不可否認性，從而保證在開放網絡環境下使用信用卡進行在線購物的安全。目前，SET已得到IBM、Microsoft、VeriSign等著名公司的參與和支持，是國際上所公認的Internet電子商務的安全標準。

1、基于SET的交易流程

SET協議的購物系統由持卡人、商家、支付網關、收單銀行、發卡銀行和證書授權中心(CA)等六大部分組成，它們之間的關系如圖1所示。

此外，基于SET協議的購物系統至少包括電子錢包軟件、商家軟件、支付網關軟件和簽發數字證書軟件。目前，SET電子錢包主要是安裝在客戶端的交易軟件，它是持卡人實現網上交易過程的主要工具。

SET協議在一般環境下的工作步驟如下：

(1)持卡人注冊：持卡人為了使用信用卡，必須向支持SET的發卡銀行申請開戶，從而獲得一個可用于Internet支付的信用卡帳號，同時向CA申請該信用卡的數字證書。此后，持卡人可以使用終端進行購物。

(2)商家注冊：商家同樣向CA申請用于電子商務支付的數字證書。此后，商家可以在網絡上開設商城來銷售貨物。

(3)持卡人利用電子商務平臺選定物品，并提交定單；

(4)商家接收定單，生成初始應答消息，數字簽名后與商家數字證書、支付網關數字證書一起發送給持卡人；

(5)持卡人對應答消息進行處理，選擇支付方式，確認定單，簽發付款指令，將定單信息和支付信息進行雙簽名，對雙簽名后的信息和用支付網關公鑰加密的支付信息簽名后連同自己的數字證書發送給商家(商家看不到持卡人的帳號信息)；

(6)商家認證持卡人數字證書和雙簽名后，生成支付認可請求，并連同加密的支付信息轉發給支付網關；

(7)支付網關通過金融專網到發卡銀行認證持卡人的帳號信息，并生成支付認可消息，數字簽名后發給商家；

(8)商家收到支付認可消息后，認證支付網關的數字簽名，生成購買定單確認信息發送給持卡人。

至此交易過程結束。商家發送貨物或提供服務并請求支付網關將購物款從發卡銀行持卡人的帳號轉賬到收單銀行商家帳號，支付網關通過金融專網完成轉賬后，生成取款應答消息發送給商家。

在以上的工作步驟當中，持卡人、商家和支付網關都通過CA來認證通信主體的身份，以確保通信的對方不是冒名頂替。

2、SET提供的功能

(1)所有信息在Internet上加密安全傳輸，保證數據不會被他人竊取。

(2)數字簽名保證信息的完整性和不可否認性。

(3)訂單信息和個人信用卡信息的隔離，使商家看不到客戶的信用卡信息。

(4)參與交易各方的身份認證，保證各方身份不可假冒。

三、SSL與SET的比較

SET是一個多方面的消息報文協議，它定義了銀行、商家、客戶之間必須符合的報文規范。SSL只是簡單地在客戶端與服務器之間建立了一個安全傳輸通道，在涉及多方的電子交易中，只能提供交易中客戶端與服務器間的認證，其并不具備商務性、服務性和集成性。SET報文能夠在銀行內部網絡或其他網絡傳輸，而SSL之上的支付系統只能與Web瀏覽器捆綁在一起。除此之外，它們還有以下區別：

1、認證機制方面，SET的安全需求較高，因此所有參與SET交易的成員都必須先申請數字證書來識別身份，而在SSL中只有商家服務器需要認證，客戶端認證是可選的。

2、對客戶而言，SET保證了商家的合法性，并且用戶的信用卡號不會被竊取。SET替客戶保守了更多的秘密使其在線購物更加輕松。在SSL協議中則缺少對商家的認證。

3、安全性上，SET的安全性較SSL高，主要原因是在整個交易中，包括客戶到商家、商家到支付網關再到銀行都受到嚴密的保護。而SSL的安全范圍只限于客戶到商家的信息交流。

四、結論

總的來講，由于SSL協議的成本低、速度快、使用簡單，對現有網絡系統不需進行大的修改，因而其應用也相對較廣泛。目前我國已有多家銀行采用SSL協議，開展網上銀行業務。SET協議比較復雜，它還要求在銀行網絡、商家服務器、客戶端的PC上安裝相應的軟件，此外還要求必須向各方發放數字證書。這些都阻止了SET的廣泛發展。但從安全性角度看，SSL協議不如SET協議安全，對于使用信用卡支付的系統來說，SET協議是最好的選擇。

結合我國的具體情況，可以預見，電子商務安全措施在我國的發展趨勢將是SET與SSL共存，優勢互補。即在商家與銀行之間采用SET協議，而與顧客連接時仍然使用SSL協議。這種方案既回避了在顧客端機器上安裝軟件。同時又可獲得了SET提供的很多優點（作者單位：溫州醫學院計算機教研室）

第三篇：SSL實驗報告

搭建證書服務器

步驟：

1、登陸Windows Server 2008服務器

2、打開【服務器管理器】

3、點擊【添加角色】，之后點擊【下一步】

4、找到【Active Directory證書服務】勾選此選項，之后點擊【下一步】；

5、進入證書服務簡介界面，點擊【下一步】

6、將證書頒發機構、證書頒發機構WEB注冊勾選上，然后點擊【下一步】

7、勾選【獨立】選項，點擊【下一步】（由于不在域管理中創建，直接默認為：“獨立”）

8、首次創建，勾選【根CA】，之后點擊【下一步】

9、首次創建勾選【新建私鑰】，之后點擊【下一步】；

10、默認，繼續點擊【下一步】；

11、默認，繼續點擊【下一步】

12、默認，繼續點擊【下一步】

13、默認，繼續點擊【下一步】

14、點擊【安裝】

15、點擊【關閉】，證書服務器安裝完成

搭建WEB服務器端SSL證書應用

步驟:

1、打開IIS，WEB服務器，找到【服務器證書】并選中

2、點擊【服務器證書】，找到【創建證書申請】項

3、單擊【創建證書申請】，打開【創建證書申請】后，填寫相關文本框，“通用名稱”必需填寫本機IP（192.168.72.128），單擊【下一步】

4、默認，點擊【下一步】

5、選擇并填寫需要生成文件的保存路徑與文件名, 此文件后期將會被使用；（保存位置、文件名可以自行設定），之后點擊【完成】，此配置完成，子界面會關閉

6、接下來，點擊IE（瀏覽器），訪問：http://192.168.72.128/certsrv/（本機ip）此時會出現證書服務頁面；點擊【申請證書】，進入下一界面點擊【高級證書申請】，進入下一界面點擊【創建并向此CA提交一個申請】，進入下一界面，此時會彈出一個提示窗口：“為了完成證書注冊，必須將該CA的網站配置為使用HTTPS身份驗證”；也就是必須將HTTP網站配置為HTTPS的網站，才能正常訪問當前網頁及功能

7、搭建HTTPS的網站：

方法：打開IE(瀏覽器)，找到工具欄，點擊【工具欄】，找到它下面的【Internet選項】；、點擊【Internet選項】->點擊【安全】->點擊【可信站點】；

10、點擊【可信站點】，并輸入之前的證書網站地址：http://192.168.72.128/certsrv，并將其【添加】到信任站點中；添加完后，點擊【關閉】，關閉子界面

11、接下來，繼續在【可信站點】位置點擊【自定義級別】，此時會彈出一個【安全設置】子界面，在安全設置界面中拖動右別的滾動條，找到【對未標記為可安全執行腳本的ActiveX控件初始化并執行腳本】選項，將選為【啟用】；之后點擊所有【確定】操作，直到【Internet選項】子界面關閉為止

12、完成上面操作后，先將IE關閉，然后重新打開，輸入：http://192.168.72.128/certsrv；頁面出來后點擊【申請證書】，【高級證書申請】，【使用base64編碼的CMC或PKCS#10文件提交一個證書申請，或使用Base64編碼的PKCS#7文件續訂證書申請】

13、將之前保存的密鑰文檔文件找到并打開，將里面的文本信息復制并粘貼到“Base-64編碼的證書申請”文本框中；確定文本內容無誤后，點擊【提交】

14、此時可以看到提交信息，申請已經提交給證書服務器，關閉當前IE

15、打開證書服務器處理用戶剛才提交的證書申請； 回到Windows【桌面】->點擊【開始】->點擊【運行】，在運行位置輸入：certsrv.msc，然后回車就會打開證書服務功能界面；

打開后，找到【掛起的申請】位置，可以看到之前提交的證書申請；

（圖17）

18、點擊鼠標右鍵會出現【所有任務】，點擊【所有任務】->點擊【頒發】將掛起的證書申請審批通過，此時掛起的證書會從當前界面消失，即代表已完成操作

19、點擊【頒發的證書】，可以看到新老已審批通過的證書

20、重新打開IE，輸入之前的網址：http://192.168.72.128/certsrv/； 打開頁面后，可點擊【查看掛起的證書申請的狀態】；之后會進入“查看掛起的證書申請的狀態”頁面，點擊【保存的申請證書】；

21、進入新頁面后，勾選Base 64編碼，然后點擊【下載證書】,將已申請成功的證書保存到指定位置，后續待用；

22、打開IIS服務器，點擊【服務器證書】->【完成證書申請】->選擇剛保存的證書，然后在“好記名稱”文本框中輸入自定義的名稱，完后點擊【確定】

23、上述操作完后，可在“服務器證書”界面下看到證書

24、點擊左邊的【Default Web Site】菜單，然后找到【綁定】功能，點擊【綁定】功能，會彈出【網站綁定】界面，默認會出現一個類型為http，端口為80的主機服務，然后點擊【添加】，會彈出【添加網站綁定】界面，在此界面中選擇“類型：https”、“SSL證書：JZT_TEST1”，然后點【確定】；點完確定后，會看到【網站綁定】子界面中有剛配的HTTPS服務，點擊【關閉】，子界面消失

25、點擊左菜單上的【CertSrv】證書服務網站，然后點擊【SSL設置】

26、進入SSL設置頁面，勾選上“要求SSL”即啟用SSL功能，然后點擊【應用】，保存設置

27、打開IE，再次輸入：https://192.168.70.128

第四篇：電子商務安全協議SSL、SET的分析與研究演講稿

第一張：標題 第二張：SSL 概念：安全套接層(Secure Sockets Layer，SSL)是一種傳輸層技術，可以實現兼容瀏覽器和服務器之間的安全通信。SSL協議是目前網上購物網站中常使用的一種安全協議。

1.SSL協議提供的服務主要有

(1)用戶和服務器的合法性認證；

(2)加密數據以隱藏被傳送的數據；(3)維護數據的完整性，2.SSL協議的工作流程

(1)接通階段：客戶通過網絡向服務商發送連接信息，服務商回應；

(2)密碼交換階段：客戶與服務器之間交換雙方認可的密碼，一般選用RSA密碼算法，也有的選用Diffie-Hellmanf和Fortezza-KEA密碼算法；

(3)會談密碼階段：客戶根據收到的服務器響應信息，產生一個主密鑰，并用服務器的公開密鑰加密后傳給服務器；

(4)檢驗階段：服務器恢復該主密鑰，并返回給客戶一個用主密鑰認證的信息，以此讓客戶認證服務器。

(5)客戶認證階段：服務器通過數字簽名驗證客戶的可信度；

(6)結束階段，客戶與服務商之間相互交換結束的信息。

3.SSL協議的缺點

（1）客戶的信息先到商家，讓商家閱讀，這樣，客戶資料的安全性就得不到保證。

（2）SSL只能保證資料信息傳遞的安全，而傳遞過程是否有人截取就無法保證了。所以，SSL并沒有實現電子支付所要求的保密性、完整性，而且多方互相認證也是很困難的。

4.電子商務中的應用。電子商務與網上銀行交易不同，因為有商戶參加，形成客戶――商家――銀行，兩次點對點的SSL連接。客戶，商家，銀行，都必須具證書，兩次點對點的雙向認證。

第三張SET 概念: SET協議是由VISA和MasterCard兩大信用卡公司于1997年5月聯合推出的規范。SET主要是為了解決用戶、商家和銀行之間通過信用卡支付的交易而設計的，以保證支付信息的機密、支付過程的完整、商戶及持卡人的合法身份、以及可操作性。SET中的核心技術主要有公開密鑰加密、電子數字簽名、電子信封、電子安全證書等。

1。SET支付系統的組成

SET支付系統主要由持卡人、商家、發卡行、收單行、支付網關、認證中心等六個部分組成。對應地，基于SET協議的網上購物系統至少包括電子錢包軟件、商家軟件、支付網關軟件和簽發證書軟件。

2。SET安全協議主要提供三方面的服務

（1）保證客戶交易信息的保密性和完整性：

（2）確保商家和客戶交易行為的不可否認性：

（3）確保商家和客戶的合法性：

3。SET協議的缺點

（1）只能建立兩點之間的安全連線，所以顧客只能把付款信息先發送到商家，再由商家轉發到銀行，而且只能保證連接通道是安全的而沒有其他保證。

（2）不能保證商家會私自保留或盜用他的付款信息。

4.SET的工作流程

①消費者在互聯網選所要購買的物品，并在計算機上輸入訂貨單

②通過電子商務服務器與有關商家聯系，商家作出應答，告訴消費者所填訂貨單的貨物單價、應付款數、交貨方式等信息是否準確、是否有變化

③消費者選擇付款方式，確認訂單，簽發付款指令，此時SET開始介入 ④在SET中，消費者必須對訂單和付款指令進行數字簽名，同時利用雙重簽名技術保證商家看不到消費者的足球新聞賬號信息

⑤商家接受訂單后，向消費者所在銀行請求支付認可，信息通過支付網關到收單銀行，再到電子貨幣發行公司確認，批準交易后，返回確認信息給商家

⑥商家發送訂單確認信息給消費者，消費者端軟件可記錄交易日志，以備查詢

⑦商家發送貨物或提供服務，并通知收單銀行將錢從消費者的賬號轉移到商店賬號，或通知發卡銀行請求支付。

第四張：SSL與SET協議的比較

（1）在認證要求方面，早期的SSL并沒有提供商家身份認證機制，不能實現多方認證；而SET的安全要求較高，所有參與SET交易的成員都必須申請數字證書進行身份識別。

（2）在安全性方面，SET協議規范了整個商務活動的流程，從而最大限度地保證了商務性、服務性、協調性和集成性。而SSL只對持卡人與商店端的信息交換進行加密保護，可以看作是用于傳輸的那部分的技術規范。從電子商務特性來看，它并不具備商務性、服務性、協調性和集成性。因此SET的安全性比SSL高。

（3）在網絡層協議位置方面，SSL是基于傳輸層的通用安全協議，而SET位于應用層，對網絡上其他各層也有涉及。

（4）在應用領域方面，SSL主要是和Web應用一起工作，而SET是為信用卡交易提供安全，但如果電子商務應用是一個涉及多方交易的過程，則使用SET更安全、更通用些。

總結

由于SSL協議的成本低、速度快、使用簡單，對現有網絡系統不需進行大的修改，因而目前取得了廣泛的應用。但隨著電子商務規模的擴大，網絡欺詐的風險性也在提高，在未來的電子商務中SET協議將會逐步占據主導地位。

第五篇：SSL(Secure Sockets Layer)協議與數字證書

SSL（Secure Sockets Layer）協議與數字證書 SSL的概述

由于 Web上有時要傳輸重要或敏感的數據，Netscape公司在推出 Web瀏覽器首版的同時，提出了安全通信協議 SSL（Secure Socket Layer）。

目的是在 Internet基礎上提供一種基于會話加密和認證的安全協議。SSL協議已成為 Internet上保密通訊的工業標準。現行 Web瀏覽器普遍將 HTTP和 SSL相結合，從而實現安全通信。

SSL協議有以下三個特性 : 保密性。因為在握手協議定義了會話密鑰后，所有的消息都被加密。

確認性。因為盡管會話的客戶端認證是可選的，但是服務器端始終是被認證的。可靠性。因為傳送的消息包括消息完整性檢查（使用 MAC）。

SSL或 TSL工作在 TCP層與 HTTP,FTP,SMTP之間.2 SSL的體系結構

SSL協議分為兩層協議。

一層是 SSL記錄協議（SSL Record Protocol），它建立在可靠的傳輸協議（如 TCP）之上，為更高層提供基本的安全服務，如提供數據封裝、壓縮、加密 等基本功能的支持。

另一層是建立在 SSL記錄協議之上，用于在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。它由三個協議組成：

? SSL握手協議（SSL Handshake Protocol）

? SSL修改密文規約協議（SSL Change Cipher Spec Protocol）? SSL告警協議（SSL Alert Protocol）

圖：SSL 協議棧

SSL中協議中兩個重要概念 ：

SSL連接（connection）：在 OSI分層模型的定義中，連接是提供一種合適類型服務的傳輸。而 SSL的連接是點對點的關系。連接是暫時的，每一個連接和一個會話關聯。

SSL會話（session）：一個 SSL會話是在客戶與服務器之間的一個關聯。會話由握手協議創建。會話定義了一組可供多個連接共享的加密安全參數。會話用以避免為每一個連接提供新的安全參數所付出昂貴的代價。

① 會話狀態 由下列參數定義：

? 會話標識符 ：服務器選擇的一個任意字節序列，用以標識一個活動的或可激活的會話狀態。

? ? ? 對方證書 ：一個 X.509.v3證書。可為空。

壓縮方法 ：加密前進行數據壓縮的算法。

密文規約 ：指明數據體加密的算法（無，或 DES等），以及用以計算 MAC散列算法（如 MD5或 SHA-1）。還包括其它參數，如散列長度，主密碼（48位 C與 S之間共享的密鑰），重新開始標志（指明該會話是否能用于產生一個新連接）。

② 連接狀態 由下列參數定義：

? ? ? 服務器和客戶的隨機數：服務器和客戶為每一個連接所選擇的字節序列。

服務器寫 MAC密碼：一個密鑰，用來對服務器發送的數據進行 MAC操作。

客戶寫 MAC密碼：一個密鑰，用來對客戶發送的數據進行 MAC操作。? 服務器寫密鑰：用于服務器進行數據加密，客戶進行數據解密的對稱加密密鑰；

? 客戶寫密鑰：用于客戶進行數據加密，服務器 r進行數據解密的對稱加密密鑰；

? 初始化向量：當數據加密采用 CBC方式時，每一個密鑰保持一個 IV。該字段首先由 SSL握手協議初始化，以后保留每次最后的密文數據塊作為下一個記錄的 IV。

? 序號：每一方為每一個連接的數據發送與接收維護單獨的順序號。當一方發送或接收一個修改的密文規約的報文時，序號置為 0，最大 264-1。SSL記錄協議

在 SSL協議中，所有的傳輸數據都被封裝在記錄中。記錄是由記錄頭和長度不為 0的記錄數據組成的。所有的 SSL通信包括握手消息、安全空白記錄和應用數據都使用 SSL記錄層。SSL記錄協議（SSL Record Protocol）包括了記錄頭和記錄數據格式的規定。

1.SSL記錄頭格式

SSL的記錄頭可以是兩個或三個字節長的編碼。SSL記錄頭的包含的信息包括：記錄頭的長度、記錄數據的長度、記錄數據中是否有粘貼數據。2.SSL記錄數據的格式

SSL的記錄數據包含三個部分： MAC(Message Authentication Code)數據、實際數據和粘貼數據。

3.SSL記錄協議操作

在 SSL的記錄層完成對數據加密、解密和認證。操作過程如圖所示：

SSL Record Protocol

All SSL protocol messages move in records of up to 32,767 bytes.Each message has a header of either 2 or 3 bytes.The headers include a security escape function, a flag to indicate the existence of padding, and the length of the message(and possibly the padding.)A two byte header has no padding, a three byte header includes some padding.The meaning of bits is as follows:

8

+----------------+-----------------+----------------+

|# S Length | Length | Padding length |

+----------------+-----------------+----------------+

# is the number of bytes in the header

0 indicates a 3 byte header, max length 32,767 bytes.1 indicates a 2 byte header, max length 16,383 bytes S

indicates the presence of a security escape, although none are

currently implemented.(Several suggestions for security

escapes are in the weaknesses section.)

There is no version information within the SSL record header, although it is available in the handshake.Within a record, there are three components: MAC-DATA, Actual-data, and Padding-data.MAC is the Message Authentication Code , Actual-data is the actual data being sent, and Padding-data is padding.The MAC-DATA is a hash of a key, the data, padding, and a sequence number.The hash is chosen based on the cipher-choice.The key used is the(sender)-write-key, which is the same key as the(receiver)-read-key.When cipher-choice is not defined, there is no mac-data or padding-data.Padding is used to ensure that the data is a multiple of the block size when a block cipher is used.Padding data is always discarded after the MAC has been calculated.Sequence numbers are unsigned 32 bit integers incremented with each message sent.Sequence numbers wrap to zero after 0xFFFFFFFF.Each dialog direction has its own sequence number.Failure to authenticate, decrypt, or otherwise get correct answers in a crytpographic operation result in I/O errors, and a close of connection.附： 主 密碼的計算

主秘密(master secret)的生成，它是從預主秘密衍生出來的。當生成了一個預主秘密并且雙方都知道它之后，就可以計算主秘密，用作共享秘密的主秘密是通過對許多先前的消息交接中的數據的雜湊計算構成的。

生成主密鑰這些計算格式如下： Master_secret= MD5（pre-master-secret+SHA（A+pre-master-secre+ClientHello.random+ServerHello.random））+ MD5（pre-master-secret+SHA（BB+pre-master-secre+ClientHello.random+ ServerHello.random））+ MD5（pre-master-secret+SHA（BB+pre-master-secre+ClientHello.random+ ServerHello.random））修改密文規約協議

修改密文規約協議（SSL Change Cipher Spec Protocol）是簡單的特定 SSL的協議。

目的：為表示密碼策略的變化。該協議包括一個單一的消息，它由記錄層按照密碼規約中所指定的方式進行加密和壓縮。在完成握手協議之前，客戶端和服務器都要 發送這一消息，以便通知對方其后的記錄將用剛剛協商的密碼規范以及相關聯的密鑰來保護。所有意外的更改密碼規范消息都將生成一個 “意外消息（unexpected_message）”警告。告警協議 警告協議將警告消息以及它們的嚴重程度傳遞給 SSL會話中的主體。就像由記錄層處理的應用層數據一樣，警告消息也用當前連接狀態所指定的方式來壓縮和加密。

當任何一方檢測到一個錯誤時，檢測的一方就向另一方發送一個消息。如果警告消息有一個致命的后果，則通信的雙方應立即關閉連接。雙方都需要忘記任何與該失敗的連接相關聯的會話標識符、密鑰和秘密。對于所有的非致命錯誤，雙方可以緩存信息以恢復該連接。握手協議

SSL握手協議負責建立當前會話狀態的參數。雙方協商一個協議版本，選擇密碼算法，互相認證（不是必需的），并且使用公鑰加密技術通過一系列交換的消息在客戶端和服務器之間生成共享密鑰。

SSL握手協議動作包含四個階段。握手協議的動作如圖所示。

第一階段 建立安全能力（1）Client Hello消息（2）Server Hello消息 第二階段 服務器認證和密鑰交換

（1）Server Certificate消息（2）Server Key Exchange消息（3）Certificate Request消息（4）Server Hello Done消息 第三階段 客戶認證和密鑰交換（1）Client Certificate消息（2）Client Key Exchange消息（3）Certificate Verify消息 第四階段 結束握手

（1）Change Cipher Spec 消息（2）Finished消息

（3）Change Cipher Spec 消息（4）Finished消息

握手交互流程：

C->S: 請求一個受保護的頁面

S->C：返回附帶公鑰的證書

C：檢查證書是否授信，不授信則提示客戶端 C：產生一臨時的對稱密鑰，并用服務端的公鑰加密

C：用服務端的公鑰加密需要請求的地址和附加的參數

C->S:將加密過的密鑰和請求內容發送給服務端

S：首先用私鑰解密獲得兩者交互的臨時對稱密鑰

S->C：將請求的內容通過臨時對稱密鑰加密返回給客戶端

C->S：通過臨時對稱密鑰開始交互

S->C：通過臨時對稱密鑰加密并返回內容

數字證書

數字證書稱為數字標識（Digital Certificate，Digital ID）。它提供了一種在 Internet 上身份驗證的方式，是用來標志和證明網絡通信雙方身份的數字信息文件，與司機駕照或日常生活中的身份證相似。數字證書它是由一個由權威機構即 CA機構，又 稱為證書授權（Certificate Authority）中心發行的，人們可以在交往中用它來識別對方的身份。在網上進行電子商務活動時，交易雙方需要使用數字證書來表明自己的身份，并使用數字證書來進行有關交易操作。通俗地講，數字證書就是個人或單位在 Internet上的身份證。

比較專業的數字證書定義是，數 字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名。一般情況下證書中還包括密鑰的有效時間，發證機關（證書授權中心）的名稱，該證書的序列號等信息，證書的格式遵循相關國際標準。有了數字證書，我們在網絡上就 可以暢通無阻。如圖(數字證書授權中心)是一個數字證書在網絡應用中的原理圖。

圖：數字證書授權中心

為什么需要數字證書呢？Internet網電子商務系統技術使在網上購物的顧客能夠極其方便輕松地獲得商家和企業的信息，但同時也增加了對某些敏感或有價值的數據被濫用的風險。買方和賣方都必須對于在因特網上進行的一切金融交易運作都是真實可靠的，并且要使顧客、商家和企業等交易各方都具有絕對的信心，因而網絡電子商務系統必須保證具有十分可靠的安全保密技術，也就是說，必須保證網絡安全的四大要素，即信息傳輸的保密性、數據交換的完整性、發送信息的不可否認性、交易者身份的確定性。

下面就是在證書中所包含的元素的列表。

? ? 版本 ：它用來區別 X.509的各種連續的版本。默認值是 1988版本。

序列號 ：序列號是一個整數值，在發行的證書頒發機構中是唯一的。序列號與證書有明確聯系，就像身份證號碼和公民日常登記有明確聯系一樣。

? 算法識別符 ：算法識別符識別證書頒發機構用來簽署證書的算法。證書頒發機構使用它的私鑰對每個證書進行簽名。

? ? 發行者或證書頒發機構 ：證書頒發機構是創建這個證書的機構。

有效期 ：提供證書有效的起止日期，類似于信用卡的期限。

?

?

主體 ：證書對他的身份進行驗證。

公鑰信息 ：為證書識別的主體提供公鑰和算法識別符。? 簽名 ：證書簽名覆蓋了證書的所有其他字段。簽名是其他字段的哈希代碼，使用證書頒發機構的私鑰進行加密，保證整個證書中信息的完整性。如果有人使用了證 書頒發機構的公鑰來解密這個哈希代碼，同時計算了證書的哈希代碼，而兩者并不相同，那么證書的某一部分就肯定被非法更改了。

圖：證書內容

有了 數字證書以后，我們可以進行發送安全的電子郵件，實現網上郵件的加密和簽名電子郵件，它還可以應用于公眾網絡上的商務活動和行政作業活動，應用范圍涉及需要身份認證及數據安全的各個行業，如訪問安全站點、網上招標投標、網上簽約、網上訂購、安全網上公文傳送、網上辦公、網上繳費、網上繳稅、網上購物等網上 的安全電子事務處理和安全電子交易活動等。隨著電子商務和電子政務的不斷發展，數字證書的頒發機構 CA中心將作為一種基礎設施為電子商務的發展提供可靠的保障。

Appendix2

SSL uses a scheme of https to reference documents available under HTTP with SSL.The https has a IANA reserved number of 443.SSL supports the RC2 & RC4 with either 128 bits or 40 bits of secret key information, as well as DES, 3 key 3DES, and IDEA.Details of all are covered in Schneier.A.The threats

As long as they confine themselves to playing by the rules established by Netscape, lookers can do little harm.There's little a looker with minimal resources can do against the deployed crypto systems used in SSL.Hacking one or more of the hosts or key certification authorities would seem to be a better option.Insiders, especially those around the top of the key certification hierarchy, have the potential to do quite a bit of harm by creating false signatures on keys.Few of these attacks will occur in a vengeful manner;they require time and foresight to enact, and are probably the domain of the malicious employee.(This assumes that employees who become vengeful do so at about the time they leave a firm.)

A criminal organization could, depending on its resources, possibly target an employee at a key certification organization.However, a more useful option might be to buy a cheap PC, and have it attempt brute force RC4 keys.It is estimated that a pentium based PC should be able to crack a 40 bit RC4 key in a month or several months using brute force.The manipulations used on the master key may increase the cost of tha attack, but probably not by orders of magnitude.If a PC costs $1500, then breaking 12 keys a year leads to a cost that could be as low as $125 per stolen card number.While this seems like a high price, the credit card numbers are acquired in a nearly risk free manner of sniffing an ethernet.In addition, that time will drop with the introduction of faster hardware.B.Protections

SSL explicitly examines a number of attacks that can be made against it, including brute force, clear text cryptanalysis, replay, and man in the middle.It does seem to protect well against those forms of attack.SSL is designed to protect at the network layer.This means it is not designed to, and does not, protect you from host breakins.To protect against host breakins, a Tripwire-like package should be integrated with the HTTPd.Tripwire uses cryptographically strong hashes to ensure documents have not been changed from some reference version.The database is usually stored on a physically write protected media like a floppy(Kim).C.Weaknesses

SSL, being a low level protocol, does little to protect you once your host is compromised.Also, once a key in a certificate is compromised, it can remain compromised, as there is no mechanism in place for consulting the root of a CA to confirm the key you are using has not been revoked.The keys however do include expiration dates.Climbing to the root CA is not a commonplace step, but a mechanism should be available to do so, for high value transactions.Out of band key repudiation is also desirable.Today, trusted key certifiers are compiled into the Netscape binary.The use of RC4 is troublesome, albeit understandable.RC4 is a newly published cipher, and although it was designed by the very competent Ron Rivest, it has not been subjected to the same kind of intense professional scrutiny that DES and IDEA have undergone.The decision to use RC4-40 is driven by the fact that it gets automatic export approval from the State Department.There are also a number of areas in the design of SSL as it stands that could become exploitable problems.None suggest an immediate means of attack, but are things which could be modified for possible added surety.Handshaking protocol: The challenge data, sent in the CLIENT-HELLO message, could in some types of handshakes, be sent later, encrypted.The data used in generating the session keys could include more data not sent in the clear.The means of generating the master key should be better specified, probably with reference to RFC-1750.Record protocol: Bad MAC-data should not terminate a connection, it should cause a repeat-request message.There are few attacks that will get anything from having the same data resent, and closing the connection on a bad message opens avenues for denial of service attacks.Sequence numbers should be randomly initialized.There are quite a few non-obvious attacks on sequence numbers(in IP, and NFS);it can't hurt to start with a non-predictable number.There should be a way for one or both sides to demand renegotiation of keys.Perhaps this could be implemented as a security escape.This is not needed for HTTP connection security, since the connections are very short lived, but if SSL is used, as the authors suggest, for telnet or FTP, the sessions could last substantially longer.