第一篇：什么是SSL安全協(xié)議

什么是SSL安全協(xié)議

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

SSL安全協(xié)議主要提供三方面的服務(wù)：

用戶(hù)和服務(wù)器的合法性認(rèn)證

認(rèn)證用戶(hù)和服務(wù)器的合法性，使得它們能夠確信數(shù)據(jù)將被發(fā)送到正確的客戶(hù)機(jī)和服務(wù)器上?？蛻?hù)機(jī)和服務(wù)器都是有各自的識(shí)別號(hào)，這些識(shí)別號(hào)由公開(kāi)密鑰進(jìn)行編號(hào)，為了驗(yàn)證用戶(hù)是否合法，安全套接層協(xié)議要求在握手交換數(shù)據(jù)時(shí)進(jìn)行數(shù)字認(rèn)證，以此來(lái)確保用戶(hù)的合法性。

加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)

安全套接層協(xié)議所采用的加密技術(shù)既有對(duì)稱(chēng)密鑰技術(shù)，也有公開(kāi)密鑰技術(shù)。在客戶(hù)機(jī)與服務(wù)器進(jìn)行數(shù)據(jù)交換之前，交換SSL初始握手信息，在SSL握手情息中采用了各種加密技術(shù)對(duì)其加密，以保證其機(jī)密性和數(shù)據(jù)的完整性，并且用數(shù)字證書(shū)進(jìn)行鑒別，這樣就可以防止非法用戶(hù)進(jìn)行破譯。

保護(hù)數(shù)據(jù)的完整性

安全套接層協(xié)議采用Hash函數(shù)和機(jī)密共享的方法來(lái)提供信息的完整性服務(wù)，建立客戶(hù)機(jī)與服務(wù)器之間的安全通道，使所有經(jīng)過(guò)安全套接層協(xié)議處理的業(yè)務(wù)在傳輸過(guò)程中能全部完整準(zhǔn)確無(wú)誤地到達(dá)目的地。

安全套接層協(xié)議是一個(gè)保證計(jì)算機(jī)通信安全的協(xié)議，對(duì)通信對(duì)話(huà)過(guò)程進(jìn)行安全保護(hù)，其實(shí)現(xiàn)過(guò)程主要經(jīng)過(guò)如下幾個(gè)階段：

1.接通階段：客戶(hù)機(jī)通過(guò)網(wǎng)絡(luò)向服務(wù)器打招呼，服務(wù)器回應(yīng);

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

3.會(huì)談密碼階段：客戶(hù)機(jī)器與服務(wù)器間產(chǎn)生彼此交談的會(huì)談密碼;

4.檢驗(yàn)階段：客戶(hù)機(jī)檢驗(yàn)服務(wù)器取得的密碼;

5.客戶(hù)認(rèn)證階段：服務(wù)器驗(yàn)證客戶(hù)機(jī)的可信度;

6.結(jié)束階段：客戶(hù)機(jī)與服務(wù)器之間相互交換結(jié)束的信息。

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

發(fā)送時(shí)信息用對(duì)稱(chēng)密鑰加密，對(duì)稱(chēng)密鑰用非對(duì)稱(chēng)算法加密，再把兩個(gè)包綁在一起傳送過(guò)去。

接收的過(guò)程與發(fā)送正好相反，先打開(kāi)有對(duì)稱(chēng)密鑰的加密包，再用對(duì)稱(chēng)密鑰解密。在電子商務(wù)交易過(guò)程中，由于有銀行參與，按照SSL協(xié)議，客戶(hù)的購(gòu)買(mǎi)信息首先發(fā)往商家，商家再將信息轉(zhuǎn)發(fā)銀行，銀行驗(yàn)證客戶(hù)信息的合法性后，通知商家付款成功，商家再通知客戶(hù)購(gòu)買(mǎi)成功，并將商品寄送客戶(hù)。

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

第二篇：淺析電子商務(wù)安全協(xié)議SSL與SET

淺析電子商務(wù)安全協(xié)議SSL與SET

一、引言

電子商務(wù)融計(jì)算機(jī)技術(shù)、通信技術(shù)、網(wǎng)絡(luò)技術(shù)于一體，以Internet為基礎(chǔ)平臺(tái)，互動(dòng)性、開(kāi)放性、廣泛性為其顯著特點(diǎn)。由于其開(kāi)放性與廣泛性，必然面臨各種安全風(fēng)險(xiǎn)，如信息泄露或被篡改、欺騙、抵賴(lài)等。所以，安全問(wèn)題已成為發(fā)展可信賴(lài)電子商務(wù)環(huán)境的瓶頸。目前，眾多的安全技術(shù)都是通過(guò)安全協(xié)議來(lái)實(shí)施的。因此，簡(jiǎn)潔、有效的安全協(xié)議對(duì)電子商務(wù)安全而言至關(guān)重要?，F(xiàn)今，國(guó)際上主要通行的兩種安全協(xié)議：安全套接層協(xié)議SSL和安全電子交易協(xié)議SET，二者均是成熟和實(shí)用的安全協(xié)議，但是由于它們的設(shè)計(jì)目的不同，所以在應(yīng)用上有很大的差別。

二、兩種電子商務(wù)安全協(xié)議介紹

（一）安全套接層協(xié)議SSL

SSL是網(wǎng)景(Netscape)公司提出的基于WEB應(yīng)用的安全協(xié)議，其目的是在Internet基礎(chǔ)上提供的一種保證機(jī)密性的安全協(xié)議。它能使客戶(hù)端／服務(wù)器應(yīng)用之間的通信不被攻擊者竊聽(tīng)，并且始終對(duì)服務(wù)器進(jìn)行認(rèn)證，而且還可選擇對(duì)客戶(hù)端進(jìn)行認(rèn)證。

SSL協(xié)議是國(guó)際上最早應(yīng)用于電子商務(wù)的一種網(wǎng)絡(luò)安全協(xié)議，主要用于提高應(yīng)用程序之間的數(shù)據(jù)安全。它同時(shí)使用對(duì)稱(chēng)加密算法和公鑰加密算法，前者在速度上比后者要快很多，但是后者可以實(shí)現(xiàn)更好的安全認(rèn)證。一個(gè)SSL傳輸過(guò)程首先需要握手：用公鑰加密算法使服務(wù)器在客戶(hù)端得到認(rèn)證，以后就可以使用雙方商議成功的對(duì)稱(chēng)密鑰來(lái)更快速的加密、解密數(shù)據(jù)。

SSL協(xié)議要求建立在可靠的傳輸層協(xié)議(例如：TCP)之上。SSL協(xié)議的優(yōu)勢(shì)在于它是與應(yīng)用層協(xié)議獨(dú)立無(wú)關(guān)的。高層的應(yīng)用層協(xié)議(例如：HTTP，F(xiàn)TP)能透明地建立于SSL協(xié)議之上。SSL協(xié)議在應(yīng)用層協(xié)議通信之前就已經(jīng)完成加密算法、通信密鑰的協(xié)商以及服務(wù)器認(rèn)證工作。應(yīng)用層協(xié)議所傳送的數(shù)據(jù)都會(huì)被加密，從而保證通信的機(jī)密性。對(duì)于電子商務(wù)應(yīng)用來(lái)說(shuō)，使用SSL可保證信息的真實(shí)性、完整性和保密性。SSL協(xié)議由SSL記錄協(xié)議和SSL握手協(xié)議兩部分組成。

1、SSL記錄協(xié)議

在SSL協(xié)議中，所有的傳輸數(shù)據(jù)都被封裝在記錄中。所有的SSL通信，包括握手消息、安全空白記錄和應(yīng)用數(shù)據(jù)都使用SSL記錄協(xié)議。記錄協(xié)議允許服務(wù)器和客戶(hù)端相互認(rèn)證并協(xié)商加密算法和密鑰，對(duì)所有發(fā)送和接收的數(shù)據(jù)進(jìn)行分段、壓縮、認(rèn)證、加密和完整性服務(wù)。

2、SSL握手協(xié)議

SSL握手協(xié)議包括建立在記錄協(xié)議之上的握手協(xié)議、警報(bào)協(xié)議、更改加密說(shuō)明協(xié)議和應(yīng)用數(shù)據(jù)協(xié)議等對(duì)會(huì)話(huà)和管理提供支持的子協(xié)議，其用于在通信雙方之間建立安全傳輸通道。握手過(guò)程一般分為4個(gè)階段：

(1)初始化邏輯連接，客戶(hù)端先發(fā)出ClientHello消息，服務(wù)器返回一個(gè)ServerHello消息，這兩個(gè)消息用來(lái)協(xié)商雙方的安全能力，包括協(xié)議版本、對(duì)稱(chēng)加密算法、壓縮算法等。

(2)服務(wù)器發(fā)送數(shù)字證書(shū)(包含了服務(wù)器的公鑰等)和會(huì)話(huà)密鑰。如果服務(wù)器要求認(rèn)證客戶(hù)端，則要發(fā)送CertificateRequest消息。最后服務(wù)器發(fā)送ServerHelloDone消息，表示hello階段結(jié)束，服務(wù)器等待客戶(hù)端的響應(yīng)。

(3)如果服務(wù)器要求認(rèn)證客戶(hù)端，則客戶(hù)端先發(fā)送Certificate消息，然后產(chǎn)生會(huì)話(huà)密鑰，并用服務(wù)器的公鑰加密，封裝在ClientKeyExchange消息中，如果客戶(hù)端發(fā)送了自己的數(shù)字證書(shū)，則再發(fā)送一個(gè)數(shù)字簽名CertificateVerify來(lái)對(duì)數(shù)字證書(shū)進(jìn)行校驗(yàn)。

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

至此，握手全部完成，雙方就可以開(kāi)始傳輸應(yīng)用數(shù)據(jù)了。

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

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

(1)信息加密?？蛻?hù)端和服務(wù)器之間的所有的應(yīng)用數(shù)據(jù)使用在SSL握手過(guò)程中建立的密鑰和算法進(jìn)行加密。這樣就防止了某些用戶(hù)通過(guò)使用IP packet sniffer等工具進(jìn)行非法竊聽(tīng)或者破譯。

(2)信息完整。SSL提供完整信息服務(wù)，以建立客戶(hù)端與服務(wù)器之間的安全通道，使所有經(jīng)過(guò)SSL協(xié)議處理的業(yè)務(wù)能全部準(zhǔn)確無(wú)誤地到達(dá)目的地。

(3)相互認(rèn)證。客戶(hù)端和服務(wù)器都有各自的識(shí)別號(hào)，這些識(shí)別號(hào)由公開(kāi)密鑰進(jìn)行編號(hào)。為了認(rèn)證用戶(hù)是否合法，SSL協(xié)議要求在握手交換數(shù)據(jù)前進(jìn)行數(shù)字認(rèn)證，來(lái)確保用戶(hù)的合法性。

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

（二）安全電子交易協(xié)議SET

安全電子交易(Secure Electronic Transaction．簡(jiǎn)稱(chēng)SET)協(xié)議是由Visa和Master Card公司在1996年底開(kāi)發(fā)的，主要為在網(wǎng)上在線(xiàn)交易時(shí)保證使用信用卡進(jìn)行支付時(shí)的安全而設(shè)立的一個(gè)開(kāi)放的協(xié)議，它是面向網(wǎng)上交易，針對(duì)利用信用卡進(jìn)行支付而設(shè)計(jì)的電子支付規(guī)范。SET提供了消費(fèi)者、商家和銀行之間的認(rèn)證，確保交易的保密性、可靠性和不可否認(rèn)性，從而保證在開(kāi)放網(wǎng)絡(luò)環(huán)境下使用信用卡進(jìn)行在線(xiàn)購(gòu)物的安全。目前，SET已得到IBM、Microsoft、VeriSign等著名公司的參與和支持，是國(guó)際上所公認(rèn)的Internet電子商務(wù)的安全標(biāo)準(zhǔn)。

1、基于SET的交易流程

SET協(xié)議的購(gòu)物系統(tǒng)由持卡人、商家、支付網(wǎng)關(guān)、收單銀行、發(fā)卡銀行和證書(shū)授權(quán)中心(CA)等六大部分組成，它們之間的關(guān)系如圖1所示。

此外，基于SET協(xié)議的購(gòu)物系統(tǒng)至少包括電子錢(qián)包軟件、商家軟件、支付網(wǎng)關(guān)軟件和簽發(fā)數(shù)字證書(shū)軟件。目前，SET電子錢(qián)包主要是安裝在客戶(hù)端的交易軟件，它是持卡人實(shí)現(xiàn)網(wǎng)上交易過(guò)程的主要工具。

SET協(xié)議在一般環(huán)境下的工作步驟如下：

(1)持卡人注冊(cè)：持卡人為了使用信用卡，必須向支持SET的發(fā)卡銀行申請(qǐng)開(kāi)戶(hù)，從而獲得一個(gè)可用于Internet支付的信用卡帳號(hào)，同時(shí)向CA申請(qǐng)?jiān)撔庞每ǖ臄?shù)字證書(shū)。此后，持卡人可以使用終端進(jìn)行購(gòu)物。

(2)商家注冊(cè)：商家同樣向CA申請(qǐng)用于電子商務(wù)支付的數(shù)字證書(shū)。此后，商家可以在網(wǎng)絡(luò)上開(kāi)設(shè)商城來(lái)銷(xiāo)售貨物。

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

(4)商家接收定單，生成初始應(yīng)答消息，數(shù)字簽名后與商家數(shù)字證書(shū)、支付網(wǎng)關(guān)數(shù)字證書(shū)一起發(fā)送給持卡人；

(5)持卡人對(duì)應(yīng)答消息進(jìn)行處理，選擇支付方式，確認(rèn)定單，簽發(fā)付款指令，將定單信息和支付信息進(jìn)行雙簽名，對(duì)雙簽名后的信息和用支付網(wǎng)關(guān)公鑰加密的支付信息簽名后連同自己的數(shù)字證書(shū)發(fā)送給商家(商家看不到持卡人的帳號(hào)信息)；

(6)商家認(rèn)證持卡人數(shù)字證書(shū)和雙簽名后，生成支付認(rèn)可請(qǐng)求，并連同加密的支付信息轉(zhuǎn)發(fā)給支付網(wǎng)關(guān)；

(7)支付網(wǎng)關(guān)通過(guò)金融專(zhuān)網(wǎng)到發(fā)卡銀行認(rèn)證持卡人的帳號(hào)信息，并生成支付認(rèn)可消息，數(shù)字簽名后發(fā)給商家；

(8)商家收到支付認(rèn)可消息后，認(rèn)證支付網(wǎng)關(guān)的數(shù)字簽名，生成購(gòu)買(mǎi)定單確認(rèn)信息發(fā)送給持卡人。

至此交易過(guò)程結(jié)束。商家發(fā)送貨物或提供服務(wù)并請(qǐng)求支付網(wǎng)關(guān)將購(gòu)物款從發(fā)卡銀行持卡人的帳號(hào)轉(zhuǎn)賬到收單銀行商家?guī)ぬ?hào)，支付網(wǎng)關(guān)通過(guò)金融專(zhuān)網(wǎng)完成轉(zhuǎn)賬后，生成取款應(yīng)答消息發(fā)送給商家。

在以上的工作步驟當(dāng)中，持卡人、商家和支付網(wǎng)關(guān)都通過(guò)CA來(lái)認(rèn)證通信主體的身份，以確保通信的對(duì)方不是冒名頂替。

2、SET提供的功能

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

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

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

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

三、SSL與SET的比較

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

1、認(rèn)證機(jī)制方面，SET的安全需求較高，因此所有參與SET交易的成員都必須先申請(qǐng)數(shù)字證書(shū)來(lái)識(shí)別身份，而在SSL中只有商家服務(wù)器需要認(rèn)證，客戶(hù)端認(rèn)證是可選的。

2、對(duì)客戶(hù)而言，SET保證了商家的合法性，并且用戶(hù)的信用卡號(hào)不會(huì)被竊取。SET替客戶(hù)保守了更多的秘密使其在線(xiàn)購(gòu)物更加輕松。在SSL協(xié)議中則缺少對(duì)商家的認(rèn)證。

3、安全性上，SET的安全性較SSL高，主要原因是在整個(gè)交易中，包括客戶(hù)到商家、商家到支付網(wǎng)關(guān)再到銀行都受到嚴(yán)密的保護(hù)。而SSL的安全范圍只限于客戶(hù)到商家的信息交流。

四、結(jié)論

總的來(lái)講，由于SSL協(xié)議的成本低、速度快、使用簡(jiǎn)單，對(duì)現(xiàn)有網(wǎng)絡(luò)系統(tǒng)不需進(jìn)行大的修改，因而其應(yīng)用也相對(duì)較廣泛。目前我國(guó)已有多家銀行采用SSL協(xié)議，開(kāi)展網(wǎng)上銀行業(yè)務(wù)。SET協(xié)議比較復(fù)雜，它還要求在銀行網(wǎng)絡(luò)、商家服務(wù)器、客戶(hù)端的PC上安裝相應(yīng)的軟件，此外還要求必須向各方發(fā)放數(shù)字證書(shū)。這些都阻止了SET的廣泛發(fā)展。但從安全性角度看，SSL協(xié)議不如SET協(xié)議安全，對(duì)于使用信用卡支付的系統(tǒng)來(lái)說(shuō)，SET協(xié)議是最好的選擇。

結(jié)合我國(guó)的具體情況，可以預(yù)見(jiàn)，電子商務(wù)安全措施在我國(guó)的發(fā)展趨勢(shì)將是SET與SSL共存，優(yōu)勢(shì)互補(bǔ)。即在商家與銀行之間采用SET協(xié)議，而與顧客連接時(shí)仍然使用SSL協(xié)議。這種方案既回避了在顧客端機(jī)器上安裝軟件。同時(shí)又可獲得了SET提供的很多優(yōu)點(diǎn)（作者單位：溫州醫(yī)學(xué)院計(jì)算機(jī)教研室）

第三篇：SSL實(shí)驗(yàn)報(bào)告

搭建證書(shū)服務(wù)器

步驟：

1、登陸Windows Server 2008服務(wù)器

2、打開(kāi)【服務(wù)器管理器】

3、點(diǎn)擊【添加角色】，之后點(diǎn)擊【下一步】

4、找到【Active Directory證書(shū)服務(wù)】勾選此選項(xiàng)，之后點(diǎn)擊【下一步】；

5、進(jìn)入證書(shū)服務(wù)簡(jiǎn)介界面，點(diǎn)擊【下一步】

6、將證書(shū)頒發(fā)機(jī)構(gòu)、證書(shū)頒發(fā)機(jī)構(gòu)WEB注冊(cè)勾選上，然后點(diǎn)擊【下一步】

7、勾選【獨(dú)立】選項(xiàng)，點(diǎn)擊【下一步】（由于不在域管理中創(chuàng)建，直接默認(rèn)為：“獨(dú)立”）

8、首次創(chuàng)建，勾選【根CA】，之后點(diǎn)擊【下一步】

9、首次創(chuàng)建勾選【新建私鑰】，之后點(diǎn)擊【下一步】；

10、默認(rèn)，繼續(xù)點(diǎn)擊【下一步】；

11、默認(rèn)，繼續(xù)點(diǎn)擊【下一步】

12、默認(rèn)，繼續(xù)點(diǎn)擊【下一步】

13、默認(rèn)，繼續(xù)點(diǎn)擊【下一步】

14、點(diǎn)擊【安裝】

15、點(diǎn)擊【關(guān)閉】，證書(shū)服務(wù)器安裝完成

搭建WEB服務(wù)器端SSL證書(shū)應(yīng)用

步驟:

1、打開(kāi)IIS，WEB服務(wù)器，找到【服務(wù)器證書(shū)】并選中

2、點(diǎn)擊【服務(wù)器證書(shū)】，找到【創(chuàng)建證書(shū)申請(qǐng)】項(xiàng)

3、單擊【創(chuàng)建證書(shū)申請(qǐng)】，打開(kāi)【創(chuàng)建證書(shū)申請(qǐng)】后，填寫(xiě)相關(guān)文本框，“通用名稱(chēng)”必需填寫(xiě)本機(jī)IP（192.168.72.128），單擊【下一步】

4、默認(rèn)，點(diǎn)擊【下一步】

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

6、接下來(lái)，點(diǎn)擊IE（瀏覽器），訪(fǎng)問(wèn)：http://192.168.72.128/certsrv/（本機(jī)ip）此時(shí)會(huì)出現(xiàn)證書(shū)服務(wù)頁(yè)面；點(diǎn)擊【申請(qǐng)證書(shū)】，進(jìn)入下一界面點(diǎn)擊【高級(jí)證書(shū)申請(qǐng)】，進(jìn)入下一界面點(diǎn)擊【創(chuàng)建并向此CA提交一個(gè)申請(qǐng)】，進(jìn)入下一界面，此時(shí)會(huì)彈出一個(gè)提示窗口：“為了完成證書(shū)注冊(cè)，必須將該CA的網(wǎng)站配置為使用HTTPS身份驗(yàn)證”；也就是必須將HTTP網(wǎng)站配置為HTTPS的網(wǎng)站，才能正常訪(fǎng)問(wèn)當(dāng)前網(wǎng)頁(yè)及功能

7、搭建HTTPS的網(wǎng)站：

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

10、點(diǎn)擊【可信站點(diǎn)】，并輸入之前的證書(shū)網(wǎng)站地址：http://192.168.72.128/certsrv，并將其【添加】到信任站點(diǎn)中；添加完后，點(diǎn)擊【關(guān)閉】，關(guān)閉子界面

11、接下來(lái)，繼續(xù)在【可信站點(diǎn)】位置點(diǎn)擊【自定義級(jí)別】，此時(shí)會(huì)彈出一個(gè)【安全設(shè)置】子界面，在安全設(shè)置界面中拖動(dòng)右別的滾動(dòng)條，找到【對(duì)未標(biāo)記為可安全執(zhí)行腳本的ActiveX控件初始化并執(zhí)行腳本】選項(xiàng)，將選為【啟用】；之后點(diǎn)擊所有【確定】操作，直到【Internet選項(xiàng)】子界面關(guān)閉為止

12、完成上面操作后，先將IE關(guān)閉，然后重新打開(kāi)，輸入：http://192.168.72.128/certsrv；頁(yè)面出來(lái)后點(diǎn)擊【申請(qǐng)證書(shū)】，【高級(jí)證書(shū)申請(qǐng)】，【使用base64編碼的CMC或PKCS#10文件提交一個(gè)證書(shū)申請(qǐng)，或使用Base64編碼的PKCS#7文件續(xù)訂證書(shū)申請(qǐng)】

13、將之前保存的密鑰文檔文件找到并打開(kāi)，將里面的文本信息復(fù)制并粘貼到“Base-64編碼的證書(shū)申請(qǐng)”文本框中；確定文本內(nèi)容無(wú)誤后，點(diǎn)擊【提交】

14、此時(shí)可以看到提交信息，申請(qǐng)已經(jīng)提交給證書(shū)服務(wù)器，關(guān)閉當(dāng)前IE

15、打開(kāi)證書(shū)服務(wù)器處理用戶(hù)剛才提交的證書(shū)申請(qǐng)； 回到Windows【桌面】->點(diǎn)擊【開(kāi)始】->點(diǎn)擊【運(yùn)行】，在運(yùn)行位置輸入：certsrv.msc，然后回車(chē)就會(huì)打開(kāi)證書(shū)服務(wù)功能界面；

打開(kāi)后，找到【掛起的申請(qǐng)】位置，可以看到之前提交的證書(shū)申請(qǐng)；

（圖17）

18、點(diǎn)擊鼠標(biāo)右鍵會(huì)出現(xiàn)【所有任務(wù)】，點(diǎn)擊【所有任務(wù)】->點(diǎn)擊【頒發(fā)】將掛起的證書(shū)申請(qǐng)審批通過(guò)，此時(shí)掛起的證書(shū)會(huì)從當(dāng)前界面消失，即代表已完成操作

19、點(diǎn)擊【頒發(fā)的證書(shū)】，可以看到新老已審批通過(guò)的證書(shū)

20、重新打開(kāi)IE，輸入之前的網(wǎng)址：http://192.168.72.128/certsrv/； 打開(kāi)頁(yè)面后，可點(diǎn)擊【查看掛起的證書(shū)申請(qǐng)的狀態(tài)】；之后會(huì)進(jìn)入“查看掛起的證書(shū)申請(qǐng)的狀態(tài)”頁(yè)面，點(diǎn)擊【保存的申請(qǐng)證書(shū)】；

21、進(jìn)入新頁(yè)面后，勾選Base 64編碼，然后點(diǎn)擊【下載證書(shū)】,將已申請(qǐng)成功的證書(shū)保存到指定位置，后續(xù)待用；

22、打開(kāi)IIS服務(wù)器，點(diǎn)擊【服務(wù)器證書(shū)】->【完成證書(shū)申請(qǐng)】->選擇剛保存的證書(shū)，然后在“好記名稱(chēng)”文本框中輸入自定義的名稱(chēng)，完后點(diǎn)擊【確定】

23、上述操作完后，可在“服務(wù)器證書(shū)”界面下看到證書(shū)

24、點(diǎn)擊左邊的【Default Web Site】菜單，然后找到【綁定】功能，點(diǎn)擊【綁定】功能，會(huì)彈出【網(wǎng)站綁定】界面，默認(rèn)會(huì)出現(xiàn)一個(gè)類(lèi)型為http，端口為80的主機(jī)服務(wù)，然后點(diǎn)擊【添加】，會(huì)彈出【添加網(wǎng)站綁定】界面，在此界面中選擇“類(lèi)型：https”、“SSL證書(shū)：JZT_TEST1”，然后點(diǎn)【確定】；點(diǎn)完確定后，會(huì)看到【網(wǎng)站綁定】子界面中有剛配的HTTPS服務(wù)，點(diǎn)擊【關(guān)閉】，子界面消失

25、點(diǎn)擊左菜單上的【CertSrv】證書(shū)服務(wù)網(wǎng)站，然后點(diǎn)擊【SSL設(shè)置】

26、進(jìn)入SSL設(shè)置頁(yè)面，勾選上“要求SSL”即啟用SSL功能，然后點(diǎn)擊【應(yīng)用】，保存設(shè)置

27、打開(kāi)IE，再次輸入：https://192.168.70.128

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

第一張：標(biāo)題 第二張：SSL 概念：安全套接層(Secure Sockets Layer，SSL)是一種傳輸層技術(shù)，可以實(shí)現(xiàn)兼容瀏覽器和服務(wù)器之間的安全通信。SSL協(xié)議是目前網(wǎng)上購(gòu)物網(wǎng)站中常使用的一種安全協(xié)議。

1.SSL協(xié)議提供的服務(wù)主要有

(1)用戶(hù)和服務(wù)器的合法性認(rèn)證；

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

(1)接通階段：客戶(hù)通過(guò)網(wǎng)絡(luò)向服務(wù)商發(fā)送連接信息，服務(wù)商回應(yīng)；

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

(3)會(huì)談密碼階段：客戶(hù)根據(jù)收到的服務(wù)器響應(yīng)信息，產(chǎn)生一個(gè)主密鑰，并用服務(wù)器的公開(kāi)密鑰加密后傳給服務(wù)器；

(4)檢驗(yàn)階段：服務(wù)器恢復(fù)該主密鑰，并返回給客戶(hù)一個(gè)用主密鑰認(rèn)證的信息，以此讓客戶(hù)認(rèn)證服務(wù)器。

(5)客戶(hù)認(rèn)證階段：服務(wù)器通過(guò)數(shù)字簽名驗(yàn)證客戶(hù)的可信度；

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

3.SSL協(xié)議的缺點(diǎn)

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

（2）SSL只能保證資料信息傳遞的安全，而傳遞過(guò)程是否有人截取就無(wú)法保證了。所以，SSL并沒(méi)有實(shí)現(xiàn)電子支付所要求的保密性、完整性，而且多方互相認(rèn)證也是很困難的。

4.電子商務(wù)中的應(yīng)用。電子商務(wù)與網(wǎng)上銀行交易不同，因?yàn)橛猩虘?hù)參加，形成客戶(hù)――商家――銀行，兩次點(diǎn)對(duì)點(diǎn)的SSL連接。客戶(hù)，商家，銀行，都必須具證書(shū)，兩次點(diǎn)對(duì)點(diǎn)的雙向認(rèn)證。

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

1。SET支付系統(tǒng)的組成

SET支付系統(tǒng)主要由持卡人、商家、發(fā)卡行、收單行、支付網(wǎng)關(guān)、認(rèn)證中心等六個(gè)部分組成。對(duì)應(yīng)地，基于SET協(xié)議的網(wǎng)上購(gòu)物系統(tǒng)至少包括電子錢(qián)包軟件、商家軟件、支付網(wǎng)關(guān)軟件和簽發(fā)證書(shū)軟件。

2。SET安全協(xié)議主要提供三方面的服務(wù)

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

（2）確保商家和客戶(hù)交易行為的不可否認(rèn)性：

（3）確保商家和客戶(hù)的合法性：

3。SET協(xié)議的缺點(diǎn)

（1）只能建立兩點(diǎn)之間的安全連線(xiàn)，所以顧客只能把付款信息先發(fā)送到商家，再由商家轉(zhuǎn)發(fā)到銀行，而且只能保證連接通道是安全的而沒(méi)有其他保證。

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

4.SET的工作流程

①消費(fèi)者在互聯(lián)網(wǎng)選所要購(gòu)買(mǎi)的物品，并在計(jì)算機(jī)上輸入訂貨單

②通過(guò)電子商務(wù)服務(wù)器與有關(guān)商家聯(lián)系，商家作出應(yīng)答，告訴消費(fèi)者所填訂貨單的貨物單價(jià)、應(yīng)付款數(shù)、交貨方式等信息是否準(zhǔn)確、是否有變化

③消費(fèi)者選擇付款方式，確認(rèn)訂單，簽發(fā)付款指令，此時(shí)SET開(kāi)始介入 ④在SET中，消費(fèi)者必須對(duì)訂單和付款指令進(jìn)行數(shù)字簽名，同時(shí)利用雙重簽名技術(shù)保證商家看不到消費(fèi)者的足球新聞賬號(hào)信息

⑤商家接受訂單后，向消費(fèi)者所在銀行請(qǐng)求支付認(rèn)可，信息通過(guò)支付網(wǎng)關(guān)到收單銀行，再到電子貨幣發(fā)行公司確認(rèn)，批準(zhǔn)交易后，返回確認(rèn)信息給商家

⑥商家發(fā)送訂單確認(rèn)信息給消費(fèi)者，消費(fèi)者端軟件可記錄交易日志，以備查詢(xún)

⑦商家發(fā)送貨物或提供服務(wù)，并通知收單銀行將錢(qián)從消費(fèi)者的賬號(hào)轉(zhuǎn)移到商店賬號(hào)，或通知發(fā)卡銀行請(qǐng)求支付。

第四張：SSL與SET協(xié)議的比較

（1）在認(rèn)證要求方面，早期的SSL并沒(méi)有提供商家身份認(rèn)證機(jī)制，不能實(shí)現(xiàn)多方認(rèn)證；而SET的安全要求較高，所有參與SET交易的成員都必須申請(qǐng)數(shù)字證書(shū)進(jìn)行身份識(shí)別。

（2）在安全性方面，SET協(xié)議規(guī)范了整個(gè)商務(wù)活動(dòng)的流程，從而最大限度地保證了商務(wù)性、服務(wù)性、協(xié)調(diào)性和集成性。而SSL只對(duì)持卡人與商店端的信息交換進(jìn)行加密保護(hù)，可以看作是用于傳輸?shù)哪遣糠值募夹g(shù)規(guī)范。從電子商務(wù)特性來(lái)看，它并不具備商務(wù)性、服務(wù)性、協(xié)調(diào)性和集成性。因此SET的安全性比SSL高。

（3）在網(wǎng)絡(luò)層協(xié)議位置方面，SSL是基于傳輸層的通用安全協(xié)議，而SET位于應(yīng)用層，對(duì)網(wǎng)絡(luò)上其他各層也有涉及。

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

總結(jié)

由于SSL協(xié)議的成本低、速度快、使用簡(jiǎn)單，對(duì)現(xiàn)有網(wǎng)絡(luò)系統(tǒng)不需進(jìn)行大的修改，因而目前取得了廣泛的應(yīng)用。但隨著電子商務(wù)規(guī)模的擴(kuò)大，網(wǎng)絡(luò)欺詐的風(fēng)險(xiǎn)性也在提高，在未來(lái)的電子商務(wù)中SET協(xié)議將會(huì)逐步占據(jù)主導(dǎo)地位。

第五篇：SSL(Secure Sockets Layer)協(xié)議與數(shù)字證書(shū)

SSL（Secure Sockets Layer）協(xié)議與數(shù)字證書(shū) SSL的概述

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

目的是在 Internet基礎(chǔ)上提供一種基于會(huì)話(huà)加密和認(rèn)證的安全協(xié)議。SSL協(xié)議已成為 Internet上保密通訊的工業(yè)標(biāo)準(zhǔn)?，F(xiàn)行 Web瀏覽器普遍將 HTTP和 SSL相結(jié)合，從而實(shí)現(xiàn)安全通信。

SSL協(xié)議有以下三個(gè)特性 : 保密性。因?yàn)樵谖帐謪f(xié)議定義了會(huì)話(huà)密鑰后，所有的消息都被加密。

確認(rèn)性。因?yàn)楸M管會(huì)話(huà)的客戶(hù)端認(rèn)證是可選的，但是服務(wù)器端始終是被認(rèn)證的?？煽啃浴Ｒ?yàn)閭魉偷南ㄏ⑼暾詸z查（使用 MAC）。

SSL或 TSL工作在 TCP層與 HTTP,FTP,SMTP之間.2 SSL的體系結(jié)構(gòu)

SSL協(xié)議分為兩層協(xié)議。

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

另一層是建立在 SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開(kāi)始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。它由三個(gè)協(xié)議組成：

? SSL握手協(xié)議（SSL Handshake Protocol）

? SSL修改密文規(guī)約協(xié)議（SSL Change Cipher Spec Protocol）? SSL告警協(xié)議（SSL Alert Protocol）

圖：SSL 協(xié)議棧

SSL中協(xié)議中兩個(gè)重要概念 ：

SSL連接（connection）：在 OSI分層模型的定義中，連接是提供一種合適類(lèi)型服務(wù)的傳輸。而 SSL的連接是點(diǎn)對(duì)點(diǎn)的關(guān)系。連接是暫時(shí)的，每一個(gè)連接和一個(gè)會(huì)話(huà)關(guān)聯(lián)。

SSL會(huì)話(huà)（session）：一個(gè) SSL會(huì)話(huà)是在客戶(hù)與服務(wù)器之間的一個(gè)關(guān)聯(lián)。會(huì)話(huà)由握手協(xié)議創(chuàng)建。會(huì)話(huà)定義了一組可供多個(gè)連接共享的加密安全參數(shù)。會(huì)話(huà)用以避免為每一個(gè)連接提供新的安全參數(shù)所付出昂貴的代價(jià)。

① 會(huì)話(huà)狀態(tài) 由下列參數(shù)定義：

? 會(huì)話(huà)標(biāo)識(shí)符 ：服務(wù)器選擇的一個(gè)任意字節(jié)序列，用以標(biāo)識(shí)一個(gè)活動(dòng)的或可激活的會(huì)話(huà)狀態(tài)。

? ? ? 對(duì)方證書(shū) ：一個(gè) X.509.v3證書(shū)?？蔀榭?。

壓縮方法 ：加密前進(jìn)行數(shù)據(jù)壓縮的算法。

密文規(guī)約 ：指明數(shù)據(jù)體加密的算法（無(wú)，或 DES等），以及用以計(jì)算 MAC散列算法（如 MD5或 SHA-1）。還包括其它參數(shù)，如散列長(zhǎng)度，主密碼（48位 C與 S之間共享的密鑰），重新開(kāi)始標(biāo)志（指明該會(huì)話(huà)是否能用于產(chǎn)生一個(gè)新連接）。

② 連接狀態(tài) 由下列參數(shù)定義：

? ? ? 服務(wù)器和客戶(hù)的隨機(jī)數(shù)：服務(wù)器和客戶(hù)為每一個(gè)連接所選擇的字節(jié)序列。

服務(wù)器寫(xiě) MAC密碼：一個(gè)密鑰，用來(lái)對(duì)服務(wù)器發(fā)送的數(shù)據(jù)進(jìn)行 MAC操作。

客戶(hù)寫(xiě) MAC密碼：一個(gè)密鑰，用來(lái)對(duì)客戶(hù)發(fā)送的數(shù)據(jù)進(jìn)行 MAC操作。? 服務(wù)器寫(xiě)密鑰：用于服務(wù)器進(jìn)行數(shù)據(jù)加密，客戶(hù)進(jìn)行數(shù)據(jù)解密的對(duì)稱(chēng)加密密鑰；

? 客戶(hù)寫(xiě)密鑰：用于客戶(hù)進(jìn)行數(shù)據(jù)加密，服務(wù)器 r進(jìn)行數(shù)據(jù)解密的對(duì)稱(chēng)加密密鑰；

? 初始化向量：當(dāng)數(shù)據(jù)加密采用 CBC方式時(shí)，每一個(gè)密鑰保持一個(gè) IV。該字段首先由 SSL握手協(xié)議初始化，以后保留每次最后的密文數(shù)據(jù)塊作為下一個(gè)記錄的 IV。

? 序號(hào)：每一方為每一個(gè)連接的數(shù)據(jù)發(fā)送與接收維護(hù)單獨(dú)的順序號(hào)。當(dāng)一方發(fā)送或接收一個(gè)修改的密文規(guī)約的報(bào)文時(shí)，序號(hào)置為 0，最大 264-1。SSL記錄協(xié)議

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

1.SSL記錄頭格式

SSL的記錄頭可以是兩個(gè)或三個(gè)字節(jié)長(zhǎng)的編碼。SSL記錄頭的包含的信息包括：記錄頭的長(zhǎng)度、記錄數(shù)據(jù)的長(zhǎng)度、記錄數(shù)據(jù)中是否有粘貼數(shù)據(jù)。2.SSL記錄數(shù)據(jù)的格式

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

3.SSL記錄協(xié)議操作

在 SSL的記錄層完成對(duì)數(shù)據(jù)加密、解密和認(rèn)證。操作過(guò)程如圖所示：

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.附： 主 密碼的計(jì)算

主秘密(master secret)的生成，它是從預(yù)主秘密衍生出來(lái)的。當(dāng)生成了一個(gè)預(yù)主秘密并且雙方都知道它之后，就可以計(jì)算主秘密，用作共享秘密的主秘密是通過(guò)對(duì)許多先前的消息交接中的數(shù)據(jù)的雜湊計(jì)算構(gòu)成的。

生成主密鑰這些計(jì)算格式如下： 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））修改密文規(guī)約協(xié)議

修改密文規(guī)約協(xié)議（SSL Change Cipher Spec Protocol）是簡(jiǎn)單的特定 SSL的協(xié)議。

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

當(dāng)任何一方檢測(cè)到一個(gè)錯(cuò)誤時(shí)，檢測(cè)的一方就向另一方發(fā)送一個(gè)消息。如果警告消息有一個(gè)致命的后果，則通信的雙方應(yīng)立即關(guān)閉連接。雙方都需要忘記任何與該失敗的連接相關(guān)聯(lián)的會(huì)話(huà)標(biāo)識(shí)符、密鑰和秘密。對(duì)于所有的非致命錯(cuò)誤，雙方可以緩存信息以恢復(fù)該連接。握手協(xié)議

SSL握手協(xié)議負(fù)責(zé)建立當(dāng)前會(huì)話(huà)狀態(tài)的參數(shù)。雙方協(xié)商一個(gè)協(xié)議版本，選擇密碼算法，互相認(rèn)證（不是必需的），并且使用公鑰加密技術(shù)通過(guò)一系列交換的消息在客戶(hù)端和服務(wù)器之間生成共享密鑰。

SSL握手協(xié)議動(dòng)作包含四個(gè)階段。握手協(xié)議的動(dòng)作如圖所示。

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

（1）Server Certificate消息（2）Server Key Exchange消息（3）Certificate Request消息（4）Server Hello Done消息 第三階段 客戶(hù)認(rèn)證和密鑰交換（1）Client Certificate消息（2）Client Key Exchange消息（3）Certificate Verify消息 第四階段 結(jié)束握手

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

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

握手交互流程：

C->S: 請(qǐng)求一個(gè)受保護(hù)的頁(yè)面

S->C：返回附帶公鑰的證書(shū)

C：檢查證書(shū)是否授信，不授信則提示客戶(hù)端 C：產(chǎn)生一臨時(shí)的對(duì)稱(chēng)密鑰，并用服務(wù)端的公鑰加密

C：用服務(wù)端的公鑰加密需要請(qǐng)求的地址和附加的參數(shù)

C->S:將加密過(guò)的密鑰和請(qǐng)求內(nèi)容發(fā)送給服務(wù)端

S：首先用私鑰解密獲得兩者交互的臨時(shí)對(duì)稱(chēng)密鑰

S->C：將請(qǐng)求的內(nèi)容通過(guò)臨時(shí)對(duì)稱(chēng)密鑰加密返回給客戶(hù)端

C->S：通過(guò)臨時(shí)對(duì)稱(chēng)密鑰開(kāi)始交互

S->C：通過(guò)臨時(shí)對(duì)稱(chēng)密鑰加密并返回內(nèi)容

數(shù)字證書(shū)

數(shù)字證書(shū)稱(chēng)為數(shù)字標(biāo)識(shí)（Digital Certificate，Digital ID）。它提供了一種在 Internet 上身份驗(yàn)證的方式，是用來(lái)標(biāo)志和證明網(wǎng)絡(luò)通信雙方身份的數(shù)字信息文件，與司機(jī)駕照或日常生活中的身份證相似。數(shù)字證書(shū)它是由一個(gè)由權(quán)威機(jī)構(gòu)即 CA機(jī)構(gòu)，又 稱(chēng)為證書(shū)授權(quán)（Certificate Authority）中心發(fā)行的，人們可以在交往中用它來(lái)識(shí)別對(duì)方的身份。在網(wǎng)上進(jìn)行電子商務(wù)活動(dòng)時(shí)，交易雙方需要使用數(shù)字證書(shū)來(lái)表明自己的身份，并使用數(shù)字證書(shū)來(lái)進(jìn)行有關(guān)交易操作。通俗地講，數(shù)字證書(shū)就是個(gè)人或單位在 Internet上的身份證。

比較專(zhuān)業(yè)的數(shù)字證書(shū)定義是，數(shù) 字證書(shū)是一個(gè)經(jīng)證書(shū)授權(quán)中心數(shù)字簽名的包含公開(kāi)密鑰擁有者信息以及公開(kāi)密鑰的文件。最簡(jiǎn)單的證書(shū)包含一個(gè)公開(kāi)密鑰、名稱(chēng)以及證書(shū)授權(quán)中心的數(shù)字簽名。一般情況下證書(shū)中還包括密鑰的有效時(shí)間，發(fā)證機(jī)關(guān)（證書(shū)授權(quán)中心）的名稱(chēng)，該證書(shū)的序列號(hào)等信息，證書(shū)的格式遵循相關(guān)國(guó)際標(biāo)準(zhǔn)。有了數(shù)字證書(shū)，我們?cè)诰W(wǎng)絡(luò)上就 可以暢通無(wú)阻。如圖(數(shù)字證書(shū)授權(quán)中心)是一個(gè)數(shù)字證書(shū)在網(wǎng)絡(luò)應(yīng)用中的原理圖。

圖：數(shù)字證書(shū)授權(quán)中心

為什么需要數(shù)字證書(shū)呢？Internet網(wǎng)電子商務(wù)系統(tǒng)技術(shù)使在網(wǎng)上購(gòu)物的顧客能夠極其方便輕松地獲得商家和企業(yè)的信息，但同時(shí)也增加了對(duì)某些敏感或有價(jià)值的數(shù)據(jù)被濫用的風(fēng)險(xiǎn)。買(mǎi)方和賣(mài)方都必須對(duì)于在因特網(wǎng)上進(jìn)行的一切金融交易運(yùn)作都是真實(shí)可靠的，并且要使顧客、商家和企業(yè)等交易各方都具有絕對(duì)的信心，因而網(wǎng)絡(luò)電子商務(wù)系統(tǒng)必須保證具有十分可靠的安全保密技術(shù)，也就是說(shuō)，必須保證網(wǎng)絡(luò)安全的四大要素，即信息傳輸?shù)谋Ｃ苄?、?shù)據(jù)交換的完整性、發(fā)送信息的不可否認(rèn)性、交易者身份的確定性。

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

? ? 版本 ：它用來(lái)區(qū)別 X.509的各種連續(xù)的版本。默認(rèn)值是 1988版本。

序列號(hào) ：序列號(hào)是一個(gè)整數(shù)值，在發(fā)行的證書(shū)頒發(fā)機(jī)構(gòu)中是唯一的。序列號(hào)與證書(shū)有明確聯(lián)系，就像身份證號(hào)碼和公民日常登記有明確聯(lián)系一樣。

? 算法識(shí)別符 ：算法識(shí)別符識(shí)別證書(shū)頒發(fā)機(jī)構(gòu)用來(lái)簽署證書(shū)的算法。證書(shū)頒發(fā)機(jī)構(gòu)使用它的私鑰對(duì)每個(gè)證書(shū)進(jìn)行簽名。

? ? 發(fā)行者或證書(shū)頒發(fā)機(jī)構(gòu) ：證書(shū)頒發(fā)機(jī)構(gòu)是創(chuàng)建這個(gè)證書(shū)的機(jī)構(gòu)。

有效期 ：提供證書(shū)有效的起止日期，類(lèi)似于信用卡的期限。

?

?

主體 ：證書(shū)對(duì)他的身份進(jìn)行驗(yàn)證。

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

圖：證書(shū)內(nèi)容

有了 數(shù)字證書(shū)以后，我們可以進(jìn)行發(fā)送安全的電子郵件，實(shí)現(xiàn)網(wǎng)上郵件的加密和簽名電子郵件，它還可以應(yīng)用于公眾網(wǎng)絡(luò)上的商務(wù)活動(dòng)和行政作業(yè)活動(dòng)，應(yīng)用范圍涉及需要身份認(rèn)證及數(shù)據(jù)安全的各個(gè)行業(yè)，如訪(fǎng)問(wèn)安全站點(diǎn)、網(wǎng)上招標(biāo)投標(biāo)、網(wǎng)上簽約、網(wǎng)上訂購(gòu)、安全網(wǎng)上公文傳送、網(wǎng)上辦公、網(wǎng)上繳費(fèi)、網(wǎng)上繳稅、網(wǎng)上購(gòu)物等網(wǎng)上 的安全電子事務(wù)處理和安全電子交易活動(dòng)等。隨著電子商務(wù)和電子政務(wù)的不斷發(fā)展，數(shù)字證書(shū)的頒發(fā)機(jī)構(gòu) CA中心將作為一種基礎(chǔ)設(shè)施為電子商務(wù)的發(fā)展提供可靠的保障。

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.