第4章-密碼技術(shù)應(yīng)用-課件

第4章密碼技術(shù)應(yīng)用4.1IPSec4.2SSL4.3S-HTTP4.4SMIME4.5SET

4.6PGP習(xí)題

第4章密碼技術(shù)應(yīng)用4.1IPSec14.1IPSec1.IPSec概述傳統(tǒng)的TCP/IP協(xié)議，IP數(shù)據(jù)包在傳輸過(guò)程中并沒(méi)有過(guò)多的安全需求，人們很容易偽造IP地址，篡改數(shù)據(jù)包內(nèi)容，重放以前的包并在傳輸途中截獲并查看包內(nèi)信息。因此不能保證自己收到的數(shù)據(jù)包來(lái)自正確的發(fā)送端，不能肯定數(shù)據(jù)是發(fā)送端的原始數(shù)據(jù)，也不能防止原始數(shù)據(jù)在傳輸過(guò)程中未被竊聽，所以本質(zhì)上說(shuō)這種協(xié)議是不安全的。為了有效保護(hù)IP數(shù)據(jù)包的安全，IPSec應(yīng)運(yùn)而生，它隨著Ipv6的制定而產(chǎn)生，鑒于Ipv4應(yīng)用的廣泛性，IPSec也提供對(duì)Ipv4的支持，不過(guò)在Ipv6中它是必須支持的，而在Ipv4中是可選的。

4.1IPSec1.IPSec概述2圖4-1IPSec結(jié)構(gòu)框架

圖4-1IPSec結(jié)構(gòu)框架3

2．IPSec的結(jié)構(gòu)(1)AH為IP數(shù)據(jù)包提供3種服務(wù)，即無(wú)連接的數(shù)據(jù)完整性驗(yàn)證、數(shù)據(jù)源身份認(rèn)證和防重放攻擊。數(shù)據(jù)完整性驗(yàn)證通過(guò)哈希函數(shù)產(chǎn)生的校驗(yàn)來(lái)保證；數(shù)據(jù)源身份認(rèn)證通過(guò)在計(jì)算驗(yàn)證碼時(shí)加入一個(gè)共享密鑰來(lái)實(shí)現(xiàn)；AH報(bào)頭中的序列號(hào)可以防止重放攻擊。

2．IPSec的結(jié)構(gòu)4(2)ESP除了為IP數(shù)據(jù)包提供AH已有的3種服務(wù)外，還提供另外兩種服務(wù)，即數(shù)據(jù)包加密、數(shù)據(jù)流加密。加密是ESP的基本功能，而數(shù)據(jù)源身份認(rèn)證、數(shù)據(jù)完整性驗(yàn)證以及防重放攻擊都是可選的。數(shù)據(jù)包加密是指對(duì)一個(gè)IP包進(jìn)行加密，可以是對(duì)整個(gè)IP包，也可以只加密IP包的負(fù)荷部分，一般用于客戶端計(jì)算機(jī)；數(shù)據(jù)源加密一般用于支持IPSec的路由器，源端路由器并不關(guān)心IP包的內(nèi)容，對(duì)整個(gè)IP包進(jìn)行加密后傳輸，目的端路由器將該包解密后把原始包繼續(xù)轉(zhuǎn)發(fā)。在實(shí)際進(jìn)行IP通信中，可以根據(jù)實(shí)際安全需求同時(shí)使用這兩種協(xié)議或選擇其中的一種。AH和ESP都可以提供驗(yàn)證服務(wù)，不過(guò)，AH提供的驗(yàn)證服務(wù)要強(qiáng)于ESP。

(2)ESP除了為IP數(shù)據(jù)包提供AH已有的3種服務(wù)外5(3)IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實(shí)體間進(jìn)行身份認(rèn)證、協(xié)商加密算法以及生成共享的會(huì)話密鑰的方法。IKE將密鑰協(xié)商的結(jié)果保留在安全聯(lián)盟(SA)中，供AH和ESP以后通信時(shí)使用。最后，解釋域(DOI)為使用IKE進(jìn)行協(xié)商SA的協(xié)議統(tǒng)一分配標(biāo)識(shí)符。共享一個(gè)DOI的協(xié)議從一個(gè)共同的命名空間中選擇安全協(xié)議和變換、共享密碼以及交互協(xié)議的標(biāo)識(shí)等，DOI將IPSec的這些RFC文檔聯(lián)系到一起。

(3)IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實(shí)體間進(jìn)行身63．IPSec的運(yùn)行模式IPSec有兩種運(yùn)行模式，即傳輸模式(TransportMode)和隧道模式(TunnelMode)。這兩種模式的主要區(qū)別是它們所保護(hù)的內(nèi)容不同，傳輸模式保護(hù)的只是IP的有效負(fù)載，而隧道模式保護(hù)的是整個(gè)IP數(shù)據(jù)包。AH和ESP都支持這兩種模式，共存在四種形式，即AH傳輸模式、ESP傳輸模式、AH隧道模式、ESP隧道模式。這些傳輸模式如圖4-2所示。

3．IPSec的運(yùn)行模式7圖4-2IPSec傳輸模式(a)AH傳輸模式；(b)AH隧道模式；(c)ESP傳輸模式；(d)ESP隧道模式

圖4-2IPSec傳輸模式81)AH傳輸模式在該模式中，AH被插入到IP頭部之后，在傳輸層協(xié)議(如TCP、UDP)或者其他IPSec協(xié)議之前。因?yàn)锳H驗(yàn)證的區(qū)域覆蓋整個(gè)IP包，包括IP包頭部，所以源/目的IP地址是不能修改的，否則會(huì)被檢測(cè)出來(lái)。如果數(shù)據(jù)包在傳送過(guò)程中經(jīng)過(guò)網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT，NetworkAddressTranslation)網(wǎng)關(guān)，其源/目的IP地址將發(fā)生改變，會(huì)造成到達(dá)目的地址后的完整性驗(yàn)證識(shí)別失敗。因此，AH在傳輸模式下和NAT是沖突的，不能同時(shí)使用?；蛘哒f(shuō)AH不能穿越NAT。

1)AH傳輸模式92)AH隧道模式在該模式中，AH插入到原始IP頭部字段之前，再在AH之前增加一個(gè)新的IP頭部。在隧道模式下，AH驗(yàn)證的區(qū)域也將覆蓋整個(gè)IP包，所以也存在AH與NAT的沖突。

2)AH隧道模式103)ESP傳輸模式在該模式中，ESP插入到IP頭部之后，ESP頭部包含SPI和序列號(hào)字段，ESP尾部包含填充、填充長(zhǎng)度和下一個(gè)頭字段。在接收端，SPI字段用于和源IP地址、IPSec協(xié)議一起組成一個(gè)三元組來(lái)惟一確定一個(gè)SA，并利用該SA進(jìn)行驗(yàn)證、解密，然后等待后續(xù)處理，所以SPI不能被加密。其次，序列號(hào)字段用于判斷包是否重復(fù)，從而防止重發(fā)攻擊。序列號(hào)不會(huì)泄漏明文中的任何機(jī)密，所以也沒(méi)有必要進(jìn)行加密。其尾部使用了ESP驗(yàn)證，因?yàn)镾A需要ESP的驗(yàn)證服務(wù)，接收端會(huì)在任何后續(xù)處理(如檢查重放、解密)之前進(jìn)行驗(yàn)證。數(shù)據(jù)包只有經(jīng)過(guò)驗(yàn)證該包沒(méi)有經(jīng)過(guò)任何修改，才會(huì)被確認(rèn)為可信任的，才會(huì)進(jìn)行候選處理。

3)ESP傳輸模式114)ESP隧道模式在該模式中，ESP插入到IP頭部之前，在ESP之前再插入新的IP頭部。與傳輸模式一樣，ESP頭部含有SPI和序列號(hào)字段，ESP尾部包含填充、填充長(zhǎng)度和下一個(gè)頭字段。如果選用了驗(yàn)證，ESP的驗(yàn)證數(shù)據(jù)字段中包含了驗(yàn)證數(shù)據(jù)。同樣ESP頭部和ESP驗(yàn)證數(shù)據(jù)字段不會(huì)被加密。內(nèi)部的IP頭部被加密和驗(yàn)證，而外部的IP頭部既沒(méi)有被加密也沒(méi)有被驗(yàn)證，不被加密是因?yàn)槁酚善餍枰@些信息為其尋找路由，不被驗(yàn)證是為了能適應(yīng)NAT等情形。

4)ESP隧道模式124.2SSL

1．SSL概述SSL(SecureSocketLayer)是由Netscape公司開發(fā)的，用于提供Internet通信的安全協(xié)議，目前已經(jīng)廣泛用于Web瀏覽器與服務(wù)器之間的身份認(rèn)證和加密數(shù)據(jù)傳輸。SSL協(xié)議位于網(wǎng)絡(luò)層協(xié)議(如TCP/IP)與各種應(yīng)用層協(xié)議(如HTTP等)之間，如圖4-3所示。在發(fā)送端，SSL層接收應(yīng)用層的數(shù)據(jù)，然后將加了密的數(shù)據(jù)發(fā)往TCP端口。在接收端，SSL從TCP端口讀取數(shù)據(jù)，解密后將數(shù)據(jù)交給應(yīng)用層。所以它為客戶端與服務(wù)器之間提供安全通信，允許雙方相互認(rèn)證、通過(guò)加密提供消息保密。

4.2SSL1．SSL概述13圖4-3SSL在TCP/IP協(xié)議棧中的位置

圖4-3SSL在TCP/IP協(xié)議棧中的位置14

2．SSL的結(jié)構(gòu)SSL被設(shè)計(jì)成使用TCP來(lái)提供一種可靠的端到端的安全服務(wù)。SSL由多個(gè)協(xié)議組成，并采用兩層體系結(jié)構(gòu)，如圖4-4所示。

圖4-4SSL協(xié)議體系結(jié)構(gòu)

2．SSL的結(jié)構(gòu)圖4-4SSL協(xié)議體系結(jié)構(gòu)15SSL中有兩個(gè)重要的概念(SSL連接和SSL會(huì)話)，具體定義如下：(1)SSL連接：連接是提供恰當(dāng)類型服務(wù)的傳輸。SSL是一種點(diǎn)對(duì)點(diǎn)連接，每次連接與一個(gè)會(huì)話相聯(lián)系。(2)SSL會(huì)話：SSL會(huì)話是客戶與服務(wù)器之間的關(guān)聯(lián)，會(huì)話通過(guò)握手協(xié)議來(lái)創(chuàng)建。會(huì)話定義了一組被多個(gè)連接共享的加密安全參數(shù)集。會(huì)話可以用來(lái)避免為每個(gè)連接進(jìn)行昂貴的新安全參數(shù)的協(xié)商。

SSL中有兩個(gè)重要的概念(SSL連接和SSL會(huì)話)，具體16

3．SSL協(xié)議1)SSL記錄協(xié)議SSL協(xié)議的底層是記錄協(xié)議層，SSL記錄協(xié)議在客戶機(jī)和服務(wù)器之間傳輸應(yīng)用數(shù)據(jù)和SSL控制數(shù)據(jù)，期間有可能需要進(jìn)行分段或把多個(gè)高層協(xié)議數(shù)據(jù)組合成單個(gè)數(shù)據(jù)單元。圖4-5描述了SSL記錄協(xié)議操作的整個(gè)過(guò)程。

3．SSL協(xié)議17圖4-5SSL記錄協(xié)議

圖4-5SSL記錄協(xié)議18(1)分段：其中每個(gè)分片報(bào)文最大不能超過(guò)16KB。(2)壓縮：該操作是可選的。目前的版本還沒(méi)有指定壓縮算法，默認(rèn)的缺省算法為空。壓縮必須是無(wú)損的，而且增加的內(nèi)容長(zhǎng)度不會(huì)超過(guò)1024B。(3)計(jì)算MAC碼：這一步需要用到客戶機(jī)與服務(wù)器共享的密鑰。(4)加密：使用加密算法對(duì)壓縮報(bào)文和MAC碼進(jìn)行加密。加密對(duì)內(nèi)容長(zhǎng)度的增加不可超過(guò)1024B。(5)增加記錄協(xié)議頭部，該頭部包含以下幾個(gè)部分：

(1)分段：其中每個(gè)分片報(bào)文最大不能超過(guò)16KB。19*內(nèi)容類型(8bit)：所封裝分段的高層協(xié)議類型。*主版本(8bit)：使用SSL協(xié)議的主要版本號(hào)，對(duì)SSLv3值為3。*次版本(8bit)：使用SSL協(xié)議的次要版本號(hào)，對(duì)SSLv3值為0。*壓縮長(zhǎng)度(16bit)：分段的字節(jié)長(zhǎng)度，不超過(guò)16KB＋2KB。圖4-6描述了SSL記錄頭部格式。

*內(nèi)容類型(8bit)：所封裝分段的高層協(xié)議類型。20圖4-6SSL記錄頭部格式

圖4-6SSL記錄頭部格式212)SSL修改密碼規(guī)格協(xié)議SSL修改密碼規(guī)格協(xié)議是SSL協(xié)議體系中最簡(jiǎn)單的一個(gè)，它由單個(gè)報(bào)文構(gòu)成，該報(bào)文由值為1的單個(gè)字節(jié)組成。這個(gè)報(bào)文的惟一目的是使得未決狀態(tài)被復(fù)制為當(dāng)前狀態(tài)，從而改變這個(gè)連接將要使用的密碼規(guī)格。

2)SSL修改密碼規(guī)格協(xié)議223)SSL告警協(xié)議告警協(xié)議通過(guò)SSL記錄協(xié)議把有關(guān)警告?zhèn)魉偷礁鱾€(gè)實(shí)體。它由兩個(gè)字節(jié)組成，分別表示告警級(jí)別和告警信息。其中告警級(jí)別有兩個(gè)：第一是代表警告，表明是一個(gè)一般警告信息；第二是代表致命錯(cuò)誤，它將終止當(dāng)前鏈接，同一個(gè)會(huì)話的其他鏈接也許可以繼續(xù)，但肯定不會(huì)再生成新的連接。告警信息則相對(duì)較多，它用告警代碼標(biāo)識(shí)。例如，0代表close_notify，表示通知接收方發(fā)送方已經(jīng)關(guān)閉本鏈接，不再發(fā)任何信息；10代表unexpected_message，表示接收到不合適的報(bào)文。

3)SSL告警協(xié)議234)SSL握手協(xié)議握手協(xié)議是SSL中最復(fù)雜的部分。這個(gè)協(xié)議使得服務(wù)器與客戶機(jī)能相互鑒別對(duì)方的身份、協(xié)商加密和MAC算法以及保護(hù)SSL記錄中發(fā)送數(shù)據(jù)的加密密鑰等。在傳輸任何應(yīng)用數(shù)據(jù)前，都必須使用握手協(xié)議。握手協(xié)議由一系列在客戶端與服務(wù)器之間交換的報(bào)文組成。所有這些報(bào)文具有三個(gè)字段：類型(指示10種報(bào)文中的一個(gè))、長(zhǎng)度(以字節(jié)為單位的報(bào)文長(zhǎng)度)、內(nèi)容(和這個(gè)報(bào)文有關(guān)的參數(shù))。SSL握手協(xié)議包含兩個(gè)階段：第一個(gè)階段用于建立私密性通信信道；第二個(gè)階段用于客戶認(rèn)證。

4)SSL握手協(xié)議24第一階段是通信的初始化階段，通信雙方都發(fā)出HELLO消息。當(dāng)雙方都接收到HELLO消息時(shí)，就有足夠的信息確定是否需要一個(gè)新的密鑰。若不需要新的密鑰，雙方立即進(jìn)入握手協(xié)議的第二階段。否則，此時(shí)服務(wù)器方的SERVER-HELLO消息將包含足夠的信息使客戶方產(chǎn)生一個(gè)新的密鑰。這些信息包括服務(wù)器所持有的證書、加密規(guī)約和連接標(biāo)識(shí)。若密鑰產(chǎn)生成功，客戶方發(fā)出CLIENT-MASTER-KEY消息，否則發(fā)出錯(cuò)誤消息。最終當(dāng)密鑰確定以后，服務(wù)器方向客戶方發(fā)出SERVER-VERIFY消息。因?yàn)橹挥袚碛泻线m的公鑰的服務(wù)器才能解開密鑰。需要注意的一點(diǎn)是，每一通信方向上都需要一對(duì)密鑰，所以一個(gè)連接需要四個(gè)密鑰，分別為客戶方的讀密鑰、客戶方的寫密鑰、服務(wù)器方的讀密鑰、服務(wù)器方的寫密鑰。

第一階段是通信的初始化階段，通信雙方都發(fā)出HELLO消息25第二階段的主要任務(wù)是對(duì)客戶進(jìn)行認(rèn)證，此時(shí)服務(wù)器已經(jīng)被認(rèn)證了。服務(wù)器方向客戶發(fā)出認(rèn)證請(qǐng)求消息：REQUEST-CERTIFICATE。當(dāng)客戶收到服務(wù)器方的認(rèn)證請(qǐng)求消息時(shí)，發(fā)出自己的證書，并且監(jiān)聽對(duì)方回送的認(rèn)證結(jié)果。而當(dāng)服務(wù)器收到客戶的認(rèn)證時(shí)，若認(rèn)證成功，則返回SERVER-FINISH消息，否則返回錯(cuò)誤消息。到此為止，握手協(xié)議全部結(jié)束。

第二階段的主要任務(wù)是對(duì)客戶進(jìn)行認(rèn)證，此時(shí)服務(wù)器已經(jīng)被認(rèn)證264．OpenSSL的安裝與應(yīng)用1)OpenSSL簡(jiǎn)介OpenSSL是基于SSLeay庫(kù)的軟件包，它是由EricA.Young和TimJ.Hudson于1995年共同開發(fā)成功的。其OpenSSL工具箱是經(jīng)過(guò)Apache型認(rèn)證認(rèn)可的，也就是說(shuō)，這是一個(gè)沒(méi)有太多限制的開放源代碼的軟件包。到目前為止，用戶已經(jīng)可以從免費(fèi)下載OpenSSL0.9.7g及其補(bǔ)丁程序。

4．OpenSSL的安裝與應(yīng)用27OpenSSL采用C語(yǔ)言作為開發(fā)語(yǔ)言，這使得OpenSSL具有優(yōu)秀的跨平臺(tái)性能，這對(duì)于廣大技術(shù)人員來(lái)說(shuō)是一件非常美妙的事情，可以在不同的平臺(tái)使用同樣熟悉的東西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平臺(tái)，這使得OpenSSL具有廣泛的適用性。OpenSSL的算法已經(jīng)非常完善，提供對(duì)SSL2.0、SSL3.0以及TLS1.0的支持。OpenSSL整個(gè)軟件包大概可以分成三個(gè)主要的功能部分：密碼算法庫(kù)、SSL協(xié)議庫(kù)以及應(yīng)用程序。

OpenSSL采用C語(yǔ)言作為開發(fā)語(yǔ)言，這使得Open282)OpenSSL安裝下載OpenSSL免費(fèi)軟件經(jīng)解壓縮，安裝方法可以參考INSTALL.*文件。OpenSSL是支持跨平臺(tái)的，它支持UNIX、DOS、Windows、OpenVMS和MacOS各類操作系統(tǒng)，具體安裝手冊(cè)可以分別查閱INSTALL、INSTALL.DJGPP、INSTALL.W32、INSTALL.VMS和INSTALL.MacOS文件。這里只講述基于UNIX和Windows下的OpenSSL安裝工作。

2)OpenSSL安裝29(1)在UNIX平臺(tái)安裝OpenSSL。在安裝OpenSSL前必須具備以下工具：make，Perl5，ANSIC編譯器，類庫(kù)和C頭文件開發(fā)環(huán)境，可支持UNIX操作系統(tǒng)。安裝過(guò)程比較簡(jiǎn)單，可以在控制臺(tái)輸入以下命令：$./config$make$maketest$makeinstall(1)在UNIX平臺(tái)安裝OpenSSL。在安裝Ope30前面的操作將在系統(tǒng)默認(rèn)位置/usr/local/ssl下創(chuàng)建并安裝OpenSSL。如果想指定安裝位置，可以輸入：$./config--prefix=/usr/local--openssldir=/usr/local/openssl更多有關(guān)./config(或./Configure)的配置可以查看相關(guān)幫助。

前面的操作將在系統(tǒng)默認(rèn)位置/usr/local/ssl31(2)在Windows平臺(tái)安裝OpenSSL。在安裝OpenSSL中，如果你的系統(tǒng)是基于Win32的，你需要安裝Perl工具；如果系統(tǒng)是基于Cygwin的，你需要安裝ActiveStatePerl。

另外，你必須具備一種C編譯器(如VisualC++，BorlandC或GNUC)。

(2)在Windows平臺(tái)安裝OpenSSL。在安裝32下面給出安裝過(guò)程：*使用VisualC++編譯器。創(chuàng)建一個(gè)OpenSSL的FIPS-certified變量并添加到選項(xiàng)“fips”。*運(yùn)行Configure：>perlConfigureVC-WIN32*組建Makefiles和可選的匯編語(yǔ)言文件；如果使用MASM，運(yùn)行>ms\do_masm；如果使用NASM，運(yùn)行>ms\do_nasm；如果不使用任何匯編語(yǔ)言文件，運(yùn)行>ms\do_ms。

下面給出安裝過(guò)程：33*最后運(yùn)行>nmake-fms\ntdll.mak。如果所有操作都成功，你將獲得一些DLL文件，它們可以在out32dll上運(yùn)行。如果你想測(cè)試這些文件，可以輸入>cdout32dll>..\ms\test*使用BorlandC++builder5編譯器。*配置BorlandBuilder：>perlConfigureBC-32*最后運(yùn)行>nmake-fms\ntdll.m34*創(chuàng)建合適的makefile：>ms\do_nasm*運(yùn)行：>make-fms\bcb.mak*使用GNUC(Cygwin)編譯器。Cygwin提供了一種在NT4.0，Windows9x，WindowsME，Windows2000，andWindowsXP的bashshell和GNU工具環(huán)境。所以用Cygwin安裝OpenSSL與在GNUbash環(huán)境下(如Linux)接近。Cygwin執(zhí)行一個(gè)Posix/Unix運(yùn)行時(shí)系統(tǒng)(cygwin1.dll)。它也可以使用MinGW創(chuàng)建Win32類庫(kù)(msvcrt.dll或crtdll.dll)，或者使用下面的步驟安裝。

*創(chuàng)建合適的makefile：35*安裝Cygwin(詳見/)。*安裝Perl并確信Cygwin與perl(5.6.1-2或更高)和ActivePerl工作在同個(gè)路徑。*運(yùn)行Cygwinbashshell。*在控制臺(tái)輸入：$tarzxvfopenssl-x.x.x.tar.gz$cdopenssl-x.x.x*安裝Cygwin(詳見http://cygwin36如果創(chuàng)建Cygwin版的OpenSSL，運(yùn)行：$./config[...]$make[...]$maketest$makeinstall如果在Cygwin上創(chuàng)建MinGW版(nativeWindows)OpenSSL，運(yùn)行：$./Configuremingw[...]$make[...]$maketest$makeinstall如果創(chuàng)建Cygwin版的OpenSSL，運(yùn)行：373)OpenSSL應(yīng)用OpenSSL的應(yīng)用一般可以分為兩種不同的方式：基于OpenSSL指令的應(yīng)用和基于OpenSSL加密庫(kù)及協(xié)議庫(kù)的應(yīng)用。前者簡(jiǎn)單，而后者相對(duì)復(fù)雜。這兩種應(yīng)用不一定是截然分離的，可以相互結(jié)合使用，比如使用SSL協(xié)議的API，但是證書使用OpenSSL的指令簽發(fā)?；贠penSSL指令的應(yīng)用很容易，只要安裝好了OpenSSL就可以開始使用。最簡(jiǎn)單的應(yīng)用就是使用Req、CA以及X509指令來(lái)簽發(fā)一個(gè)證書，該證書可以用于各種目的，比如很多Apache服務(wù)器就是使用OpenSSL的指令生成的證書作為服務(wù)器證書的。此外，作為測(cè)試目的，使用OpenSSL指令生成一個(gè)證書也是不錯(cuò)的選擇。

3)OpenSSL應(yīng)用38單純依靠OpenSSL指令的成功應(yīng)用要數(shù)OpenCA，它是一個(gè)完全基于OpenSSL指令開發(fā)的證書認(rèn)證中心(CA)程序，沒(méi)有使用任何OpenSSL的API。當(dāng)然，它不僅僅使用了OpenSSL一個(gè)軟件包，它還使用了諸如OpenLDAP等軟件包。OpenCA從一個(gè)側(cè)面證明了OpenSSL指令的作用是很全面的。基于OpenSSL函數(shù)庫(kù)的應(yīng)用相對(duì)于基于OpenSSL指令的應(yīng)用開發(fā)的工作量會(huì)大很多，但這并不意味著其應(yīng)用會(huì)更少。事實(shí)上，基于OpenSSL的應(yīng)用大部分是這種方式的，這種方式使得開發(fā)者能夠根據(jù)自己的需求靈活地進(jìn)行選擇，而不必受OpenSSL有限指令的限制。

單純依靠OpenSSL指令的成功應(yīng)用要數(shù)OpenCA39Mod_SSL是一個(gè)基于OpenSSL指令應(yīng)用的范例，Apache和Mod_SSL結(jié)合起來(lái)實(shí)現(xiàn)了HTTPS在Linux和Windows等平臺(tái)的運(yùn)行。Stunnel是另外一個(gè)成功應(yīng)用OpenSSL函數(shù)庫(kù)的程序，該程序提供了一種包含客戶端和服務(wù)器的安全代理服務(wù)器功能，事實(shí)上就是在客戶端和服務(wù)器使用OpenSSL來(lái)建立一條安全的SSL通道。除了這些廣為人知的項(xiàng)目外，有很多公司的商業(yè)密碼產(chǎn)品都是基于OpenSSL的函數(shù)庫(kù)開發(fā)的，在OpenSSL提供了Engine機(jī)制后，這種勢(shì)頭會(huì)更加明顯。當(dāng)然，出于各種目的，相當(dāng)一部分公司在自己的產(chǎn)品中不會(huì)聲明這一點(diǎn)。

Mod_SSL是一個(gè)基于OpenSSL指令應(yīng)用的范例，404.3S-HTTP1．安全超文本傳輸協(xié)議(S-HTTP)簡(jiǎn)介安全超文本傳輸協(xié)議(S-HTTP)是一種面向安全信息通信的協(xié)議，它可以和HTTP結(jié)合起來(lái)使用。S-HTTP能和HTTP信息模型共存并易于與HTTP應(yīng)用程序相整合。S-HTTP協(xié)議為HTTP客戶機(jī)和服務(wù)器提供了多種安全機(jī)制，提供安全服務(wù)選項(xiàng)是為了適用于萬(wàn)維網(wǎng)上各類潛在用戶。S-HTTP為客戶機(jī)和服務(wù)器提供了相同的性能(同等對(duì)待請(qǐng)求和應(yīng)答，也同等對(duì)待客戶機(jī)和服務(wù)器)，同時(shí)維持了HTTP的事務(wù)模型和實(shí)施特征。

4.3S-HTTP1．安全超文本傳輸協(xié)議(S-HT41S-HTTP客戶機(jī)和服務(wù)器能與某些加密信息格式標(biāo)準(zhǔn)相結(jié)合。S-HTTP支持多種兼容方案并且與HTTP相兼容。使用S-HTTP的客戶機(jī)能夠與沒(méi)有使用S-HTTP的服務(wù)器連接，反之亦然，但是這樣的通信明顯地不會(huì)利用S-HTTP的安全特征。S-HTTP不需要客戶端公用密鑰認(rèn)證(或公用密鑰)，但它支持對(duì)稱密鑰的操作模式，這點(diǎn)很重要，因?yàn)檫@意味著即使沒(méi)有要求用戶擁有公用密鑰，私人交易也會(huì)發(fā)生。雖然S-HTTP可以利用大多現(xiàn)有的認(rèn)證系統(tǒng)，但S-HTTP的應(yīng)用并不必依賴這些系統(tǒng)。

S-HTTP客戶機(jī)和服務(wù)器能與某些加密信息格式標(biāo)準(zhǔn)相結(jié)合42S-HTTP支持端對(duì)端的安全事務(wù)通信?？蛻魴C(jī)可能“首先”啟動(dòng)安全傳輸(使用報(bào)頭的信息)，例如它可以用來(lái)支持已填表單的加密。使用S-HTTP，敏感的數(shù)據(jù)信息不會(huì)以明文形式在網(wǎng)絡(luò)上發(fā)送。S-HTTP提供了完整且靈活的加密算法、模態(tài)及相關(guān)參數(shù)。選項(xiàng)談判用來(lái)決定客戶機(jī)和服務(wù)器在事務(wù)模式、加密算法(用于簽名的RSA和DSA、用于加密的DES和RC2等)及證書選擇方面取得一致意見。

S-HTTP支持端對(duì)端的安全事務(wù)通信。客戶機(jī)可能“首先”43雖然S-HTTP的設(shè)計(jì)者承認(rèn)他有意識(shí)地利用了多根分層的信任模型和許多公鑰證書系統(tǒng)，但S-HTTP仍努力避開對(duì)某種特定模型的濫用。S-HTTP與摘要驗(yàn)證(在[RFC-2617]中有描述)的不同之處在于，它支持公鑰加密和數(shù)字簽名，并具有保密性。HTTPS作為另一種安全Web通信技術(shù)，是指HTTP運(yùn)行在TLS和SSL上面的實(shí)現(xiàn)安全Web事務(wù)的協(xié)議。

雖然S-HTTP的設(shè)計(jì)者承認(rèn)他有意識(shí)地利用了多根分層的信44

2．協(xié)議結(jié)構(gòu)在語(yǔ)法上，S-HTTP報(bào)文與HTTP相同，由請(qǐng)求或狀態(tài)行組成，后面是信頭和主體。顯然信頭各不相同并且主體密碼設(shè)置更為精密。正如HTTP報(bào)文一樣，S-HTTP報(bào)文由從客戶機(jī)到服務(wù)器的請(qǐng)求和從服務(wù)器到客戶機(jī)的響應(yīng)組成。請(qǐng)求報(bào)文的格式如下：

2．協(xié)議結(jié)構(gòu)45為了和HTTP報(bào)文區(qū)分開來(lái)，S-HTTP需要特殊處理，請(qǐng)求行使用特殊的“安全”途徑和指定協(xié)議“S-HTTP”。因此S-HTTP和HTTP可以在相同的TCP端口混合處理(例如端口80)。為了防止敏感信息的泄漏，URI請(qǐng)求必須帶有“*”。S-HTTP響應(yīng)采用指定協(xié)議“S-HTTP”。響應(yīng)報(bào)文的格式如下：

為了和HTTP報(bào)文區(qū)分開來(lái)，S-HTTP需要特殊處理，請(qǐng)464.4SMIME

1．多用途的網(wǎng)際郵件擴(kuò)充協(xié)議(MIME/S-MIME)多用途網(wǎng)際郵件擴(kuò)充協(xié)議(MIME，MultipurposeInternetMailExtensions)說(shuō)明了如何安排消息格式使消息在不同的郵件系統(tǒng)內(nèi)進(jìn)行交換。MIME的格式靈活，允許郵件中包含任意類型的文件。MIME消息可以包含文本、圖像、聲音、視頻及其他應(yīng)用程序的特定數(shù)據(jù)。具體來(lái)說(shuō)，MIME允許郵件包括：?jiǎn)蝹€(gè)消息中可含多個(gè)對(duì)象；文本文檔不限制一行長(zhǎng)度或全文長(zhǎng)度；可傳輸ASCII以外的字符集，允許非英語(yǔ)語(yǔ)種的消息；多字體消息；二進(jìn)制或特定應(yīng)用程序文件；圖像、聲音、視頻及多媒體消息。

4.4SMIME1．多用途的網(wǎng)際郵件擴(kuò)充協(xié)議(MI47MIME復(fù)合消息的目錄信息頭設(shè)有分界標(biāo)志，這個(gè)分界標(biāo)志絕不可出現(xiàn)在消息的其他位置，而只能是在各部之間以及消息體的開始和結(jié)束處。MIME的安全版本S/MIME(Secure/MultipurposeInternetMailExtensions)設(shè)計(jì)用來(lái)支持郵件的加密。基于MIME標(biāo)準(zhǔn)，S/MIME為電子消息應(yīng)用程序提供如下加密安全服務(wù)：認(rèn)證、完整性保護(hù)、鑒定及數(shù)據(jù)保密等。

MIME復(fù)合消息的目錄信息頭設(shè)有分界標(biāo)志，這個(gè)分界標(biāo)志絕48傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME來(lái)加密發(fā)送郵件及解密接收郵件。S/MIME并不限于郵件的使用，它也能應(yīng)用于任何可以傳送MIME數(shù)據(jù)的傳輸機(jī)制，例如HTTP。同樣，S/MIME利用MIME的面向?qū)ο筇卣髟试S在混合傳輸系統(tǒng)中交換安全消息。此外，S/MIME還可應(yīng)用于消息自動(dòng)傳送代理，它們使用不需任何人為操作的加密安全服務(wù)，例如軟件文檔簽名、發(fā)送到網(wǎng)上的FAX加密等。

傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME來(lái)加密發(fā)492．協(xié)議結(jié)構(gòu)MIME定義了許多新的RFC822頭域用于描述一個(gè)MIME實(shí)體的內(nèi)容。這些頭域有兩種情形(一種作為常規(guī)RFC822消息頭的一部分，一種是多個(gè)結(jié)構(gòu)中的MIME主體部分頭)。這些正規(guī)頭域的定義如下：entity-headers:=[contentCRLF][encodingCRLF][idCRLF][descriptionCRLF]2．協(xié)議結(jié)構(gòu)50*(MIME-extension-fieldCRLF)MIME-message-headers:=entity-headers[fields]versionCRLF;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.MIME-part-headers:=entity-headers[fields];Anyfieldnotbeginningwith"content-"canhavenodefinedmeaningandmaybeignored.;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.*(MIME-extension-fieldCRLF)51MIME加入安全特性就是S/MIME，它是MIME的延伸，RFC1847就是S/MIME的標(biāo)準(zhǔn)。當(dāng)一篇MIME加入電子簽章或編碼后，S/MIME會(huì)把整個(gè)MIME郵件視作一個(gè)不可分割的主體，對(duì)這個(gè)主體實(shí)施PKI安全操作(加密或簽名等)，并加入必需的S/MIME頭信息，這樣就產(chǎn)生了S/MIME格式的郵件。

MIME加入安全特性就是S/MIME，它是MIME的延伸52(1)經(jīng)過(guò)數(shù)字簽名的郵件結(jié)構(gòu)如圖4-7所示。

圖4-7經(jīng)過(guò)數(shù)字簽名的郵件結(jié)構(gòu)

(1)經(jīng)過(guò)數(shù)字簽名的郵件結(jié)構(gòu)如圖4-7所示。圖4-753(2)經(jīng)過(guò)加密的郵件如圖4-8所示。

圖4-8經(jīng)過(guò)加密的郵件

(2)經(jīng)過(guò)加密的郵件如圖4-8所示。圖4-8經(jīng)過(guò)加密544.5SET1．SET簡(jiǎn)介電子商務(wù)是在開放的Internet環(huán)境中實(shí)現(xiàn)交易應(yīng)用。電子商務(wù)涉及資金流和物流信息的傳送，因此安全至關(guān)重要。

4.5SET1．SET簡(jiǎn)介55針對(duì)電子商務(wù)的要求，目前最有影響力的安全協(xié)議是安全電子交易協(xié)議(SET，SecureElectronicTransaction)。該協(xié)議是由VISA和MasterCard兩大信用卡公司于1997年5月聯(lián)合推出的。SET采用公鑰密碼體制和X.509數(shù)字證書標(biāo)準(zhǔn)，它主要是為了解決用戶、商家和銀行之間通過(guò)信用卡支付的交易而設(shè)計(jì)的，以保證支付信息的機(jī)密、支付過(guò)程的完整、商戶及持卡人的合法身份以及可操作性。SET協(xié)議中的核心技術(shù)主要有公鑰加密、數(shù)字簽名、電子信封、電子安全證書等。SET協(xié)議是PKI框架下的一個(gè)典型實(shí)現(xiàn)，也是一個(gè)基于可信的第三方認(rèn)證中心的方案，它不僅加密兩個(gè)端點(diǎn)間的單個(gè)會(huì)話，還可以加密和認(rèn)定三方間的多個(gè)信息。

針對(duì)電子商務(wù)的要求，目前最有影響力的安全協(xié)議是安全電子交56SET協(xié)議的目標(biāo)：(1)信息在Internet上的安全傳輸，保證網(wǎng)上傳輸?shù)臄?shù)據(jù)不被黑客竊聽。(2)訂單信息和個(gè)人賬號(hào)信息的隔離，在將包括消費(fèi)者賬號(hào)信息的訂單送到商家時(shí)，商家只能看到訂貨信息，而看不到消費(fèi)者的賬戶信息。(3)消費(fèi)者和商家的相互認(rèn)證，以確定通信雙方的身份，一般由第三方機(jī)構(gòu)負(fù)責(zé)為在線通信雙方提供信用擔(dān)保。

SET協(xié)議的目標(biāo)：57(4)要求軟件遵循相同的協(xié)議和消息格式，使不同廠家開發(fā)的軟件具有兼容和互操作功能，并且可以運(yùn)行在不同的硬件和操作系統(tǒng)平臺(tái)上。在一次完整的電子商務(wù)交易中，SET涉及到持卡人、商家、收單銀行、發(fā)卡機(jī)構(gòu)、認(rèn)證中心(CA)、支付網(wǎng)關(guān)等實(shí)體，具體關(guān)系如圖4-9所示。

(4)要求軟件遵循相同的協(xié)議和消息格式，使不同廠家開發(fā)58圖4-9SET協(xié)議的電子商務(wù)模型

圖4-9SET協(xié)議的電子商務(wù)模型59圖4-9電子商務(wù)模型中各實(shí)體的具體含義如下：*持卡人：在電子商務(wù)環(huán)境中，消費(fèi)者和團(tuán)體購(gòu)買者通過(guò)計(jì)算機(jī)與商家交流，持卡人通過(guò)由發(fā)卡機(jī)構(gòu)頒發(fā)的付款卡(例如信用卡、借記卡)進(jìn)行結(jié)算。在持卡人和商家的會(huì)話中，SET可以保證持卡人的個(gè)人賬號(hào)信息不被泄漏。*商家：提供商品或服務(wù)，使用SET就可以保證持卡人個(gè)人信息的安全。接收卡的商家必須和銀行有關(guān)系。

圖4-9電子商務(wù)模型中各實(shí)體的具體含義如下：60*收單銀行：在線交易的商家在銀行開立賬號(hào)，并且處理支付卡的認(rèn)證和支付。*發(fā)卡機(jī)構(gòu)：它是一個(gè)金融機(jī)構(gòu)，為每一個(gè)建立了賬戶的顧客頒發(fā)付款卡，發(fā)卡機(jī)構(gòu)根據(jù)不同品牌卡的規(guī)定和政策，保證對(duì)每一筆認(rèn)證交易的付款。*認(rèn)證中心(CA)：通常是由一些發(fā)卡機(jī)構(gòu)共同委托，并負(fù)責(zé)向持卡人、電子商家發(fā)行公開密鑰證書的機(jī)構(gòu)。*支付網(wǎng)關(guān)：是由銀行操作的，將Internet上的傳輸數(shù)據(jù)轉(zhuǎn)換為金融機(jī)構(gòu)內(nèi)部數(shù)據(jù)的設(shè)備，或由指派的第三方處理商家支付信息和顧客的支付指令。

*收單銀行：在線交易的商家在銀行開立賬號(hào)，并且處理支付61

2．SET交易流程SET的交易流程分為以下幾個(gè)步驟：(1)卡用戶向商家發(fā)送訂購(gòu)和支付信息，其中支付信息被加密，商家無(wú)從得知。(2)商家將支付信息發(fā)送到收單銀行，收單銀行解密信用卡號(hào)，并通過(guò)認(rèn)證驗(yàn)證簽名。(3)收單銀行向發(fā)卡銀行查詢，確認(rèn)用戶信用卡是否屬實(shí)。(4)發(fā)卡銀行認(rèn)可并簽證該筆交易。(5)收單銀行認(rèn)可商家并簽證此交易。

2．SET交易流程62(6)商家向用戶傳送貨物和收據(jù)。(7)交易成功后，商家向收單銀行請(qǐng)求支付。(8)收單銀行按合同將貨款劃給商家。(9)發(fā)卡銀行定期向用戶寄去信用卡消費(fèi)賬單。

(6)商家向用戶傳送貨物和收據(jù)。633．雙重簽名雙重簽名是為了保證消費(fèi)者的賬號(hào)等重要信息不被商家知道。SET中采用了雙重簽名技術(shù)，它是SET推出的數(shù)字簽名的新應(yīng)用。首先生成兩條消息的摘要，將兩個(gè)摘要連接起來(lái)，生成一個(gè)新的摘要(稱為雙重簽名)，然后用簽發(fā)者的私有密鑰加密，為了讓接收者驗(yàn)證雙重簽名，還必須將另外一條消息的摘要一起傳送過(guò)去。這樣，任何一個(gè)消息的接收者都可以通過(guò)以下方法驗(yàn)證消息的真實(shí)性：生成消息摘要，將它和另外一個(gè)消息摘要連接起來(lái)，生成新的摘要，如果它與解密后的雙重簽名相等，就可以確定消息是真實(shí)的。

3．雙重簽名644.6PGP1．PGP簡(jiǎn)介PGP(PrettyGoodPrivacy)是美國(guó)的PhilZimmermann在1995年開發(fā)的，它是一個(gè)基于RSA公鑰加密體系的郵件加密軟件包。它可以保密郵件以防止非授權(quán)者閱讀，它還能對(duì)郵件加上數(shù)字簽名從而使收信人可以確信郵件的發(fā)送者。PGP可以使得用戶和他從未見過(guò)的人安全通信，而事先并不需要任何保密的渠道用來(lái)傳遞私鑰。4.6PGP1．PGP簡(jiǎn)介65圖4-10PGP加密和認(rèn)證過(guò)程

圖4-10PGP加密和認(rèn)證過(guò)程662．PGP的應(yīng)用PGP既是一個(gè)特定的安全E-mail應(yīng)用，又是一個(gè)安全E-mail標(biāo)準(zhǔn)。盡管標(biāo)準(zhǔn)委員會(huì)并沒(méi)有把它規(guī)定為安全E-mail的標(biāo)準(zhǔn)，但PGP在全球的廣泛應(yīng)用已經(jīng)使它成為一個(gè)事實(shí)上的標(biāo)準(zhǔn)。目前，PGP在Windows下發(fā)布的最高版本是7.0.3。雖然它在網(wǎng)絡(luò)上是免費(fèi)的，但應(yīng)用程序是相對(duì)獨(dú)立的，與郵件的結(jié)合依賴于Outlook等郵件客戶機(jī)。所有的郵件傳遞都是后臺(tái)工作，基本不需要用戶直接干預(yù)。在PGP算法的基礎(chǔ)上，依照它的模型實(shí)現(xiàn)郵件的安全傳輸。

2．PGP的應(yīng)用67當(dāng)文件以收件人的公鑰加密后，只有持有私鑰的收件人才能解讀，即使文件被竊取也不怕資料外泄；再者，送件人以個(gè)人私鑰加簽于文件上，收件人取得后，以送件人的公鑰加以核算，若一致就表示這份文件確實(shí)是由對(duì)方發(fā)出而且沒(méi)有遭到篡改，基本上可達(dá)到文件加密及電子簽章的功能。

當(dāng)文件以收件人的公鑰加密后，只有持有私鑰的收件人才能解讀68習(xí)

題

4.1IPSec協(xié)議的隧道模式與傳輸模式有何區(qū)別？如何實(shí)現(xiàn)？4.2簡(jiǎn)述ESP和AH在IPSec中的作用，它們能否同時(shí)使用？4.3描述SSL結(jié)構(gòu)，并介紹相關(guān)協(xié)議的功能。4.4簡(jiǎn)述SSL記錄協(xié)議操作的整個(gè)過(guò)程。4.5簡(jiǎn)述S-HTTP相對(duì)于HTTP的特性。4.6SET如何在電子商務(wù)流程中實(shí)現(xiàn)安全保密功能？4.7簡(jiǎn)述PGP的加密和認(rèn)證過(guò)程。

習(xí)題4.1IPSec協(xié)議的隧道模式與傳輸模式有69第4章密碼技術(shù)應(yīng)用4.1IPSec4.2SSL4.3S-HTTP4.4SMIME4.5SET

4.6PGP習(xí)題

第4章密碼技術(shù)應(yīng)用4.1IPSec704.1IPSec1.IPSec概述傳統(tǒng)的TCP/IP協(xié)議，IP數(shù)據(jù)包在傳輸過(guò)程中并沒(méi)有過(guò)多的安全需求，人們很容易偽造IP地址，篡改數(shù)據(jù)包內(nèi)容，重放以前的包并在傳輸途中截獲并查看包內(nèi)信息。因此不能保證自己收到的數(shù)據(jù)包來(lái)自正確的發(fā)送端，不能肯定數(shù)據(jù)是發(fā)送端的原始數(shù)據(jù)，也不能防止原始數(shù)據(jù)在傳輸過(guò)程中未被竊聽，所以本質(zhì)上說(shuō)這種協(xié)議是不安全的。為了有效保護(hù)IP數(shù)據(jù)包的安全，IPSec應(yīng)運(yùn)而生，它隨著Ipv6的制定而產(chǎn)生，鑒于Ipv4應(yīng)用的廣泛性，IPSec也提供對(duì)Ipv4的支持，不過(guò)在Ipv6中它是必須支持的，而在Ipv4中是可選的。

4.1IPSec1.IPSec概述71圖4-1IPSec結(jié)構(gòu)框架

圖4-1IPSec結(jié)構(gòu)框架72

2．IPSec的結(jié)構(gòu)(1)AH為IP數(shù)據(jù)包提供3種服務(wù)，即無(wú)連接的數(shù)據(jù)完整性驗(yàn)證、數(shù)據(jù)源身份認(rèn)證和防重放攻擊。數(shù)據(jù)完整性驗(yàn)證通過(guò)哈希函數(shù)產(chǎn)生的校驗(yàn)來(lái)保證；數(shù)據(jù)源身份認(rèn)證通過(guò)在計(jì)算驗(yàn)證碼時(shí)加入一個(gè)共享密鑰來(lái)實(shí)現(xiàn)；AH報(bào)頭中的序列號(hào)可以防止重放攻擊。

2．IPSec的結(jié)構(gòu)73(2)ESP除了為IP數(shù)據(jù)包提供AH已有的3種服務(wù)外，還提供另外兩種服務(wù)，即數(shù)據(jù)包加密、數(shù)據(jù)流加密。加密是ESP的基本功能，而數(shù)據(jù)源身份認(rèn)證、數(shù)據(jù)完整性驗(yàn)證以及防重放攻擊都是可選的。數(shù)據(jù)包加密是指對(duì)一個(gè)IP包進(jìn)行加密，可以是對(duì)整個(gè)IP包，也可以只加密IP包的負(fù)荷部分，一般用于客戶端計(jì)算機(jī)；數(shù)據(jù)源加密一般用于支持IPSec的路由器，源端路由器并不關(guān)心IP包的內(nèi)容，對(duì)整個(gè)IP包進(jìn)行加密后傳輸，目的端路由器將該包解密后把原始包繼續(xù)轉(zhuǎn)發(fā)。在實(shí)際進(jìn)行IP通信中，可以根據(jù)實(shí)際安全需求同時(shí)使用這兩種協(xié)議或選擇其中的一種。AH和ESP都可以提供驗(yàn)證服務(wù)，不過(guò)，AH提供的驗(yàn)證服務(wù)要強(qiáng)于ESP。

(2)ESP除了為IP數(shù)據(jù)包提供AH已有的3種服務(wù)外74(3)IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實(shí)體間進(jìn)行身份認(rèn)證、協(xié)商加密算法以及生成共享的會(huì)話密鑰的方法。IKE將密鑰協(xié)商的結(jié)果保留在安全聯(lián)盟(SA)中，供AH和ESP以后通信時(shí)使用。最后，解釋域(DOI)為使用IKE進(jìn)行協(xié)商SA的協(xié)議統(tǒng)一分配標(biāo)識(shí)符。共享一個(gè)DOI的協(xié)議從一個(gè)共同的命名空間中選擇安全協(xié)議和變換、共享密碼以及交互協(xié)議的標(biāo)識(shí)等，DOI將IPSec的這些RFC文檔聯(lián)系到一起。

(3)IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實(shí)體間進(jìn)行身753．IPSec的運(yùn)行模式IPSec有兩種運(yùn)行模式，即傳輸模式(TransportMode)和隧道模式(TunnelMode)。這兩種模式的主要區(qū)別是它們所保護(hù)的內(nèi)容不同，傳輸模式保護(hù)的只是IP的有效負(fù)載，而隧道模式保護(hù)的是整個(gè)IP數(shù)據(jù)包。AH和ESP都支持這兩種模式，共存在四種形式，即AH傳輸模式、ESP傳輸模式、AH隧道模式、ESP隧道模式。這些傳輸模式如圖4-2所示。

3．IPSec的運(yùn)行模式76圖4-2IPSec傳輸模式(a)AH傳輸模式；(b)AH隧道模式；(c)ESP傳輸模式；(d)ESP隧道模式

圖4-2IPSec傳輸模式771)AH傳輸模式在該模式中，AH被插入到IP頭部之后，在傳輸層協(xié)議(如TCP、UDP)或者其他IPSec協(xié)議之前。因?yàn)锳H驗(yàn)證的區(qū)域覆蓋整個(gè)IP包，包括IP包頭部，所以源/目的IP地址是不能修改的，否則會(huì)被檢測(cè)出來(lái)。如果數(shù)據(jù)包在傳送過(guò)程中經(jīng)過(guò)網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT，NetworkAddressTranslation)網(wǎng)關(guān)，其源/目的IP地址將發(fā)生改變，會(huì)造成到達(dá)目的地址后的完整性驗(yàn)證識(shí)別失敗。因此，AH在傳輸模式下和NAT是沖突的，不能同時(shí)使用?；蛘哒f(shuō)AH不能穿越NAT。

1)AH傳輸模式782)AH隧道模式在該模式中，AH插入到原始IP頭部字段之前，再在AH之前增加一個(gè)新的IP頭部。在隧道模式下，AH驗(yàn)證的區(qū)域也將覆蓋整個(gè)IP包，所以也存在AH與NAT的沖突。

2)AH隧道模式793)ESP傳輸模式在該模式中，ESP插入到IP頭部之后，ESP頭部包含SPI和序列號(hào)字段，ESP尾部包含填充、填充長(zhǎng)度和下一個(gè)頭字段。在接收端，SPI字段用于和源IP地址、IPSec協(xié)議一起組成一個(gè)三元組來(lái)惟一確定一個(gè)SA，并利用該SA進(jìn)行驗(yàn)證、解密，然后等待后續(xù)處理，所以SPI不能被加密。其次，序列號(hào)字段用于判斷包是否重復(fù)，從而防止重發(fā)攻擊。序列號(hào)不會(huì)泄漏明文中的任何機(jī)密，所以也沒(méi)有必要進(jìn)行加密。其尾部使用了ESP驗(yàn)證，因?yàn)镾A需要ESP的驗(yàn)證服務(wù)，接收端會(huì)在任何后續(xù)處理(如檢查重放、解密)之前進(jìn)行驗(yàn)證。數(shù)據(jù)包只有經(jīng)過(guò)驗(yàn)證該包沒(méi)有經(jīng)過(guò)任何修改，才會(huì)被確認(rèn)為可信任的，才會(huì)進(jìn)行候選處理。

3)ESP傳輸模式804)ESP隧道模式在該模式中，ESP插入到IP頭部之前，在ESP之前再插入新的IP頭部。與傳輸模式一樣，ESP頭部含有SPI和序列號(hào)字段，ESP尾部包含填充、填充長(zhǎng)度和下一個(gè)頭字段。如果選用了驗(yàn)證，ESP的驗(yàn)證數(shù)據(jù)字段中包含了驗(yàn)證數(shù)據(jù)。同樣ESP頭部和ESP驗(yàn)證數(shù)據(jù)字段不會(huì)被加密。內(nèi)部的IP頭部被加密和驗(yàn)證，而外部的IP頭部既沒(méi)有被加密也沒(méi)有被驗(yàn)證，不被加密是因?yàn)槁酚善餍枰@些信息為其尋找路由，不被驗(yàn)證是為了能適應(yīng)NAT等情形。

4)ESP隧道模式814.2SSL

1．SSL概述SSL(SecureSocketLayer)是由Netscape公司開發(fā)的，用于提供Internet通信的安全協(xié)議，目前已經(jīng)廣泛用于Web瀏覽器與服務(wù)器之間的身份認(rèn)證和加密數(shù)據(jù)傳輸。SSL協(xié)議位于網(wǎng)絡(luò)層協(xié)議(如TCP/IP)與各種應(yīng)用層協(xié)議(如HTTP等)之間，如圖4-3所示。在發(fā)送端，SSL層接收應(yīng)用層的數(shù)據(jù)，然后將加了密的數(shù)據(jù)發(fā)往TCP端口。在接收端，SSL從TCP端口讀取數(shù)據(jù)，解密后將數(shù)據(jù)交給應(yīng)用層。所以它為客戶端與服務(wù)器之間提供安全通信，允許雙方相互認(rèn)證、通過(guò)加密提供消息保密。

4.2SSL1．SSL概述82圖4-3SSL在TCP/IP協(xié)議棧中的位置

圖4-3SSL在TCP/IP協(xié)議棧中的位置83

2．SSL的結(jié)構(gòu)SSL被設(shè)計(jì)成使用TCP來(lái)提供一種可靠的端到端的安全服務(wù)。SSL由多個(gè)協(xié)議組成，并采用兩層體系結(jié)構(gòu)，如圖4-4所示。

圖4-4SSL協(xié)議體系結(jié)構(gòu)

2．SSL的結(jié)構(gòu)圖4-4SSL協(xié)議體系結(jié)構(gòu)84SSL中有兩個(gè)重要的概念(SSL連接和SSL會(huì)話)，具體定義如下：(1)SSL連接：連接是提供恰當(dāng)類型服務(wù)的傳輸。SSL是一種點(diǎn)對(duì)點(diǎn)連接，每次連接與一個(gè)會(huì)話相聯(lián)系。(2)SSL會(huì)話：SSL會(huì)話是客戶與服務(wù)器之間的關(guān)聯(lián)，會(huì)話通過(guò)握手協(xié)議來(lái)創(chuàng)建。會(huì)話定義了一組被多個(gè)連接共享的加密安全參數(shù)集。會(huì)話可以用來(lái)避免為每個(gè)連接進(jìn)行昂貴的新安全參數(shù)的協(xié)商。

SSL中有兩個(gè)重要的概念(SSL連接和SSL會(huì)話)，具體85

3．SSL協(xié)議1)SSL記錄協(xié)議SSL協(xié)議的底層是記錄協(xié)議層，SSL記錄協(xié)議在客戶機(jī)和服務(wù)器之間傳輸應(yīng)用數(shù)據(jù)和SSL控制數(shù)據(jù)，期間有可能需要進(jìn)行分段或把多個(gè)高層協(xié)議數(shù)據(jù)組合成單個(gè)數(shù)據(jù)單元。圖4-5描述了SSL記錄協(xié)議操作的整個(gè)過(guò)程。

3．SSL協(xié)議86圖4-5SSL記錄協(xié)議

圖4-5SSL記錄協(xié)議87(1)分段：其中每個(gè)分片報(bào)文最大不能超過(guò)16KB。(2)壓縮：該操作是可選的。目前的版本還沒(méi)有指定壓縮算法，默認(rèn)的缺省算法為空。壓縮必須是無(wú)損的，而且增加的內(nèi)容長(zhǎng)度不會(huì)超過(guò)1024B。(3)計(jì)算MAC碼：這一步需要用到客戶機(jī)與服務(wù)器共享的密鑰。(4)加密：使用加密算法對(duì)壓縮報(bào)文和MAC碼進(jìn)行加密。加密對(duì)內(nèi)容長(zhǎng)度的增加不可超過(guò)1024B。(5)增加記錄協(xié)議頭部，該頭部包含以下幾個(gè)部分：

(1)分段：其中每個(gè)分片報(bào)文最大不能超過(guò)16KB。88*內(nèi)容類型(8bit)：所封裝分段的高層協(xié)議類型。*主版本(8bit)：使用SSL協(xié)議的主要版本號(hào)，對(duì)SSLv3值為3。*次版本(8bit)：使用SSL協(xié)議的次要版本號(hào)，對(duì)SSLv3值為0。*壓縮長(zhǎng)度(16bit)：分段的字節(jié)長(zhǎng)度，不超過(guò)16KB＋2KB。圖4-6描述了SSL記錄頭部格式。

*內(nèi)容類型(8bit)：所封裝分段的高層協(xié)議類型。89圖4-6SSL記錄頭部格式

圖4-6SSL記錄頭部格式902)SSL修改密碼規(guī)格協(xié)議SSL修改密碼規(guī)格協(xié)議是SSL協(xié)議體系中最簡(jiǎn)單的一個(gè)，它由單個(gè)報(bào)文構(gòu)成，該報(bào)文由值為1的單個(gè)字節(jié)組成。這個(gè)報(bào)文的惟一目的是使得未決狀態(tài)被復(fù)制為當(dāng)前狀態(tài)，從而改變這個(gè)連接將要使用的密碼規(guī)格。

2)SSL修改密碼規(guī)格協(xié)議913)SSL告警協(xié)議告警協(xié)議通過(guò)SSL記錄協(xié)議把有關(guān)警告?zhèn)魉偷礁鱾€(gè)實(shí)體。它由兩個(gè)字節(jié)組成，分別表示告警級(jí)別和告警信息。其中告警級(jí)別有兩個(gè)：第一是代表警告，表明是一個(gè)一般警告信息；第二是代表致命錯(cuò)誤，它將終止當(dāng)前鏈接，同一個(gè)會(huì)話的其他鏈接也許可以繼續(xù)，但肯定不會(huì)再生成新的連接。告警信息則相對(duì)較多，它用告警代碼標(biāo)識(shí)。例如，0代表close_notify，表示通知接收方發(fā)送方已經(jīng)關(guān)閉本鏈接，不再發(fā)任何信息；10代表unexpected_message，表示接收到不合適的報(bào)文。

3)SSL告警協(xié)議924)SSL握手協(xié)議握手協(xié)議是SSL中最復(fù)雜的部分。這個(gè)協(xié)議使得服務(wù)器與客戶機(jī)能相互鑒別對(duì)方的身份、協(xié)商加密和MAC算法以及保護(hù)SSL記錄中發(fā)送數(shù)據(jù)的加密密鑰等。在傳輸任何應(yīng)用數(shù)據(jù)前，都必須使用握手協(xié)議。握手協(xié)議由一系列在客戶端與服務(wù)器之間交換的報(bào)文組成。所有這些報(bào)文具有三個(gè)字段：類型(指示10種報(bào)文中的一個(gè))、長(zhǎng)度(以字節(jié)為單位的報(bào)文長(zhǎng)度)、內(nèi)容(和這個(gè)報(bào)文有關(guān)的參數(shù))。SSL握手協(xié)議包含兩個(gè)階段：第一個(gè)階段用于建立私密性通信信道；第二個(gè)階段用于客戶認(rèn)證。

4)SSL握手協(xié)議93第一階段是通信的初始化階段，通信雙方都發(fā)出HELLO消息。當(dāng)雙方都接收到HELLO消息時(shí)，就有足夠的信息確定是否需要一個(gè)新的密鑰。若不需要新的密鑰，雙方立即進(jìn)入握手協(xié)議的第二階段。否則，此時(shí)服務(wù)器方的SERVER-HELLO消息將包含足夠的信息使客戶方產(chǎn)生一個(gè)新的密鑰。這些信息包括服務(wù)器所持有的證書、加密規(guī)約和連接標(biāo)識(shí)。若密鑰產(chǎn)生成功，客戶方發(fā)出CLIENT-MASTER-KEY消息，否則發(fā)出錯(cuò)誤消息。最終當(dāng)密鑰確定以后，服務(wù)器方向客戶方發(fā)出SERVER-VERIFY消息。因?yàn)橹挥袚碛泻线m的公鑰的服務(wù)器才能解開密鑰。需要注意的一點(diǎn)是，每一通信方向上都需要一對(duì)密鑰，所以一個(gè)連接需要四個(gè)密鑰，分別為客戶方的讀密鑰、客戶方的寫密鑰、服務(wù)器方的讀密鑰、服務(wù)器方的寫密鑰。

第一階段是通信的初始化階段，通信雙方都發(fā)出HELLO消息94第二階段的主要任務(wù)是對(duì)客戶進(jìn)行認(rèn)證，此時(shí)服務(wù)器已經(jīng)被認(rèn)證了。服務(wù)器方向客戶發(fā)出認(rèn)證請(qǐng)求消息：REQUEST-CERTIFICATE。當(dāng)客戶收到服務(wù)器方的認(rèn)證請(qǐng)求消息時(shí)，發(fā)出自己的證書，并且監(jiān)聽對(duì)方回送的認(rèn)證結(jié)果。而當(dāng)服務(wù)器收到客戶的認(rèn)證時(shí)，若認(rèn)證成功，則返回SERVER-FINISH消息，否則返回錯(cuò)誤消息。到此為止，握手協(xié)議全部結(jié)束。

第二階段的主要任務(wù)是對(duì)客戶進(jìn)行認(rèn)證，此時(shí)服務(wù)器已經(jīng)被認(rèn)證954．OpenSSL的安裝與應(yīng)用1)OpenSSL簡(jiǎn)介OpenSSL是基于SSLeay庫(kù)的軟件包，它是由EricA.Young和TimJ.Hudson于1995年共同開發(fā)成功的。其OpenSSL工具箱是經(jīng)過(guò)Apache型認(rèn)證認(rèn)可的，也就是說(shuō)，這是一個(gè)沒(méi)有太多限制的開放源代碼的軟件包。到目前為止，用戶已經(jīng)可以從免費(fèi)下載OpenSSL0.9.7g及其補(bǔ)丁程序。

4．OpenSSL的安裝與應(yīng)用96OpenSSL采用C語(yǔ)言作為開發(fā)語(yǔ)言，這使得OpenSSL具有優(yōu)秀的跨平臺(tái)性能，這對(duì)于廣大技術(shù)人員來(lái)說(shuō)是一件非常美妙的事情，可以在不同的平臺(tái)使用同樣熟悉的東西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平臺(tái)，這使得OpenSSL具有廣泛的適用性。OpenSSL的算法已經(jīng)非常完善，提供對(duì)SSL2.0、SSL3.0以及TLS1.0的支持。OpenSSL整個(gè)軟件包大概可以分成三個(gè)主要的功能部分：密碼算法庫(kù)、SSL協(xié)議庫(kù)以及應(yīng)用程序。

OpenSSL采用C語(yǔ)言作為開發(fā)語(yǔ)言，這使得Open972)OpenSSL安裝下載OpenSSL免費(fèi)軟件經(jīng)解壓縮，安裝方法可以參考INSTALL.*文件。OpenSSL是支持跨平臺(tái)的，它支持UNIX、DOS、Windows、OpenVMS和MacOS各類操作系統(tǒng)，具體安裝手冊(cè)可以分別查閱INSTALL、INSTALL.DJGPP、INSTALL.W32、INSTALL.VMS和INSTALL.MacOS文件。這里只講述基于UNIX和Windows下的OpenSSL安裝工作。

2)OpenSSL安裝98(1)在UNIX平臺(tái)安裝OpenSSL。在安裝OpenSSL前必須具備以下工具：make，Perl5，ANSIC編譯器，類庫(kù)和C頭文件開發(fā)環(huán)境，可支持UNIX操作系統(tǒng)。安裝過(guò)程比較簡(jiǎn)單，可以在控制臺(tái)輸入以下命令：$./config$make$maketest$makeinstall(1)在UNIX平臺(tái)安裝OpenSSL。在安裝Ope99前面的操作將在系統(tǒng)默認(rèn)位置/usr/local/ssl下創(chuàng)建并安裝OpenSSL。如果想指定安裝位置，可以輸入：$./config--prefix=/usr/local--openssldir=/usr/local/openssl更多有關(guān)./config(或./Configure)的配置可以查看相關(guān)幫助。

前面的操作將在系統(tǒng)默認(rèn)位置/usr/local/ssl100(2)在Windows平臺(tái)安裝OpenSSL。在安裝OpenSSL中，如果你的系統(tǒng)是基于Win32的，你需要安裝Perl工具；如果系統(tǒng)是基于Cygwin的，你需要安裝ActiveStatePerl。

另外，你必須具備一種C編譯器(如VisualC++，BorlandC或GNUC)。

(2)在Windows平臺(tái)安裝OpenSSL。在安裝101下面給出安裝過(guò)程：*使用VisualC++編譯器。創(chuàng)建一個(gè)OpenSSL的FIPS-certified變量并添加到選項(xiàng)“fips”。*運(yùn)行Configure：>perlConfigureVC-WIN32*組建Makefiles和可選的匯編語(yǔ)言文件；如果使用MASM，運(yùn)行>ms\do_masm；如果使用NASM，運(yùn)行>ms\do_nasm；如果不使用任何匯編語(yǔ)言文件，運(yùn)行>ms\do_ms。

下面給出安裝過(guò)程：102*最后運(yùn)行>nmake-fms\ntdll.mak。如果所有操作都成功，你將獲得一些DLL文件，它們可以在out32dll上運(yùn)行。如果你想測(cè)試這些文件，可以輸入>cdout32dll>..\ms\test*使用BorlandC++builder5編譯器。*配置BorlandBuilder：>perlConfigureBC-32*最后運(yùn)行>nmake-fms\ntdll.m103*創(chuàng)建合適的makefile：>ms\do_nasm*運(yùn)行：>make-fms\bcb.mak*使用GNUC(Cygwin)編譯器。Cygwin提供了一種在NT4.0，Windows9x，WindowsME，Windows2000，andWindowsXP的bashshell和GNU工具環(huán)境。所以用Cygwin安裝OpenSSL與在GNUbash環(huán)境下(如Linux)接近。Cygwin執(zhí)行一個(gè)Posix/Unix運(yùn)行時(shí)系統(tǒng)(cygwin1.dll)。它也可以使用MinGW創(chuàng)建Win32類庫(kù)(msvcrt.dll或crtdll.dll)，或者使用下面的步驟安裝。

*創(chuàng)建合適的makefile：104*安裝Cygwin(詳見/)。*安裝Perl并確信Cygwin與perl(5.6.1-2或更高)和ActivePerl工作在同個(gè)路徑。*運(yùn)行Cygwinbashshell。*在控制臺(tái)輸入：$tarzxvfopenssl-x.x.x.tar.gz$cdopenssl-x.x.x*安裝Cygwin(詳見http://cygwin105如果創(chuàng)建Cygwin版的OpenSSL，運(yùn)行：$./config[...]$make[...]$maketest$makeinstall如果在Cygwin上創(chuàng)建MinGW版(nativeWindows)OpenSSL，運(yùn)行：$./Configuremingw[...]$make[...]$maketest$makeinstall如果創(chuàng)建Cygwin版的OpenSSL，運(yùn)行：1063)OpenSSL應(yīng)用OpenSSL的應(yīng)用一般可以分為兩種不同的方式：基于OpenSSL指令的應(yīng)用和基于OpenSSL加密庫(kù)及協(xié)議庫(kù)的應(yīng)用。前者簡(jiǎn)單，而后者相對(duì)復(fù)雜。這兩種應(yīng)用不一定是截然分離的，可以相互結(jié)合使用，比如使用SSL協(xié)議的API，但是證書使用OpenSSL的指令簽發(fā)。基于OpenSSL指令的應(yīng)用很容易，只要安裝好了OpenSSL就可以開始使用。最簡(jiǎn)單的應(yīng)用就是使用Req、CA以及X509指令來(lái)簽發(fā)一個(gè)證書，該證書可以用于各種目的，比如很多Apache服務(wù)器就是使用OpenSSL的指令生成的證書作為服務(wù)器證書的。此外，作為測(cè)試目的，使用OpenSSL指令生成一個(gè)證書也是不錯(cuò)的選擇。

3)OpenSSL應(yīng)用107單純依靠OpenSSL指令的成功應(yīng)用要數(shù)OpenCA，它是一個(gè)完全基于OpenSSL指令開發(fā)的證書認(rèn)證中心(CA)程序，沒(méi)有使用任何OpenSSL的API。當(dāng)然，它不僅僅使用了OpenSSL一個(gè)軟件包，它還使用了諸如OpenLDAP等軟件包。OpenCA從一個(gè)側(cè)面證明了OpenSSL指令的作用是很全面的。基于OpenSSL函數(shù)庫(kù)的應(yīng)用相對(duì)于基于OpenSSL指令的應(yīng)用開發(fā)的工作量會(huì)大很多，但這并不意味著其應(yīng)用會(huì)更少。事實(shí)上，基于OpenSSL的應(yīng)用大部分是這種方式的，這種方式使得開發(fā)者能夠根據(jù)自己的需求靈活地進(jìn)行選擇，而不必受OpenSSL有限指令的限制。

單純依靠OpenSSL指令的成功應(yīng)用要數(shù)OpenCA108Mod_SSL是一個(gè)基于OpenSSL指令應(yīng)用的范例，Apache和Mod_SSL結(jié)合起來(lái)實(shí)現(xiàn)了HTTPS在Linux和Windows等平臺(tái)的運(yùn)行。Stunnel是另外一個(gè)成功應(yīng)用OpenSSL函數(shù)庫(kù)的程序，該程序提供了一種包含客戶端和服務(wù)器的安全代理服務(wù)器功能，事實(shí)上就是在客戶端和服務(wù)器使用OpenSSL來(lái)建立一條安全的SSL通道。除了這些廣為人知的項(xiàng)目外，有很多公司的商業(yè)密碼產(chǎn)品都是基于OpenSSL的函數(shù)庫(kù)開發(fā)的，在OpenSSL提供了Engine機(jī)制后，這種勢(shì)頭會(huì)更加明顯。當(dāng)然，出于各種目的，相當(dāng)一部分公司在自己的產(chǎn)品中不會(huì)聲明這一點(diǎn)。

Mod_SSL是一個(gè)基于OpenSSL指令應(yīng)用的范例，1094.3S-HTTP1．安全超文本傳輸協(xié)議(S-HTTP)簡(jiǎn)介安全超文本傳輸協(xié)議(S-HTTP)是一種面向安全信息通信的協(xié)議，它可以和HTTP結(jié)合起來(lái)使用。S-HTTP能和HTTP信息模型共存并易于與HTTP應(yīng)用程序相整合。S-HTTP協(xié)議為HTTP客戶機(jī)和服務(wù)器提供了多種安全機(jī)制，提供安全服務(wù)選項(xiàng)是為了適用于萬(wàn)維網(wǎng)上各類潛在用戶。S-HTTP為客戶機(jī)和服務(wù)器提供了相同的性能(同等對(duì)待請(qǐng)求和應(yīng)答，也同等對(duì)待客戶機(jī)和服務(wù)器)，同時(shí)維持了HTTP的事務(wù)模型和實(shí)施特征。

4.3S-HTTP1．安全超文本傳輸協(xié)議(S-HT110S-HTTP客戶機(jī)和服務(wù)器能與某些加密信息格式標(biāo)準(zhǔn)相結(jié)合。S-HTTP支持多種兼容方案并且與HTTP相兼容。使用S-HTTP的客戶機(jī)能夠與沒(méi)有使用S-HTTP的服務(wù)器連接，反之亦然，但是這樣的通信明顯地不會(huì)利用S-HTTP的安全特征。S-HTTP不需要客戶端公用密鑰認(rèn)證(或公用密鑰)，但它支持對(duì)稱密鑰的操作模式，這點(diǎn)很重要，因?yàn)檫@意味著即使沒(méi)有要求用戶擁有公用密鑰，私人交易也會(huì)發(fā)生。雖然S-HTTP可以利用大多現(xiàn)有的認(rèn)證系統(tǒng)，但S-HTTP的應(yīng)用并不必依賴這些系統(tǒng)。

S-HTTP客戶機(jī)和服務(wù)器能與某些加密信息格式標(biāo)準(zhǔn)相結(jié)合111S-HTTP支持端對(duì)端的安全事務(wù)通信?？蛻魴C(jī)可能“首先”啟動(dòng)安全傳輸(使用報(bào)頭的信息)，例如它可以用來(lái)支持已填表單的加密。使用S-HTTP，敏感的數(shù)據(jù)信息不會(huì)以明文形式在網(wǎng)絡(luò)上發(fā)送。S-HTTP提供了完整且靈活的加密算法、模態(tài)及相關(guān)參數(shù)。選項(xiàng)談判用來(lái)決定客戶機(jī)和服務(wù)器在事務(wù)模式、加密算法(用于簽名的RSA和DSA、用于加密的DES和RC2等)及證書選擇方面取得一致意見。

S-HTTP支持端對(duì)端的安全事務(wù)通信?？蛻魴C(jī)可能“首先”112雖然S-HTTP的設(shè)計(jì)者承認(rèn)他有意識(shí)地利用了多根分層的信任模型和許多公鑰證書系統(tǒng)，但S-HTTP仍努力避開對(duì)某種特定模型的濫用。S-HTTP與摘要驗(yàn)證(在[RFC-2617]中有描述)的不同之處在于，它支持公鑰加密和數(shù)字簽名，并具有保密性。HTTPS作為另一種安全Web通信技術(shù)，是指HTTP運(yùn)行在TLS和SSL上面的實(shí)現(xiàn)安全Web事務(wù)的協(xié)議。

雖然S-HTTP的設(shè)計(jì)者承認(rèn)他有意識(shí)地利用了多根分層的信113

2．協(xié)議結(jié)構(gòu)在語(yǔ)法上，S-HTTP報(bào)文與HTTP相同，由請(qǐng)求或狀態(tài)行組成，后面是信頭和主體。顯然信頭各不相同并且主體密碼設(shè)置更為精密。正如HTTP報(bào)文一樣，S-HTTP報(bào)文由從客戶機(jī)到服務(wù)器的請(qǐng)求和從服務(wù)器到客戶機(jī)的響應(yīng)組成。請(qǐng)求報(bào)文的格式如下：

2．協(xié)議結(jié)構(gòu)114為了和HTTP報(bào)文區(qū)分開來(lái)，S-HTTP需要特殊處理，請(qǐng)求行使用特殊的“安全”途徑和指定協(xié)議“S-HTTP”。因此S-HTTP和HTTP可以在相同的TCP端口混合處理(例如端口80)。為了防止敏感信息的泄漏，URI請(qǐng)求必須帶有“*”。S-HTTP響應(yīng)采用指定協(xié)議“S-HTTP”。響應(yīng)報(bào)文的格式如下：

為了和HTTP報(bào)文區(qū)分開來(lái)，S-HTTP需要特殊處理，請(qǐng)1154.4SMIME

1．多用途的網(wǎng)際郵件擴(kuò)充協(xié)議(MIME/S-MIME)多用途網(wǎng)際郵件擴(kuò)充協(xié)議(MIME，MultipurposeInternetMailExtensions)說(shuō)明了如何安排消息格式使消息在不同的郵件系統(tǒng)內(nèi)進(jìn)行交換。MIME的格式靈活，允許郵件中包含任意類型的文件。MIME消息可以包含文本、圖像、聲音、視頻及其他應(yīng)用程序的特定數(shù)據(jù)。具體來(lái)說(shuō)，MIME允許郵件包括：?jiǎn)蝹€(gè)消息中可含多個(gè)對(duì)象；文本文檔不限制一行長(zhǎng)度或全文長(zhǎng)度；可傳輸ASCII以外的字符集，允許非英語(yǔ)語(yǔ)種的消息；多字體消息；二進(jìn)制或特定應(yīng)用程序文件；圖像、聲音、視頻及多媒體消息。

4.4SMIME1．多用途的網(wǎng)際郵件擴(kuò)充協(xié)議(MI116MIME復(fù)合消息的目錄信息頭設(shè)有分界標(biāo)志，這個(gè)分界標(biāo)志絕不可出現(xiàn)在消息的其他位置，而只能是在各部之間以及消息體的開始和結(jié)束處。MIME的安全版本S/MIME(Secure/MultipurposeInternetMailExtensions)設(shè)計(jì)用來(lái)支持郵件的加密?；贛IME標(biāo)準(zhǔn)，S/MIME為電子消息應(yīng)用程序提供如下加密安全服務(wù)：認(rèn)證、完整性保護(hù)、鑒定及數(shù)據(jù)保密等。

MIME復(fù)合消息的目錄信息頭設(shè)有分界標(biāo)志，這個(gè)分界標(biāo)志絕117傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME來(lái)加密發(fā)送郵件及解密接收郵件。S/MIME并不限于郵件的使用，它也能應(yīng)用于任何可以傳送MIME數(shù)據(jù)的傳輸機(jī)制，例如HTTP。同樣，S/MIME利用MIME的面向?qū)ο筇卣髟试S在混合傳輸系統(tǒng)中交換安全消息。此外，S/MIME還可應(yīng)用于消息自動(dòng)傳送代理，它們使用不需任何人為操作的加密安全服務(wù)，例如軟件文檔簽名、發(fā)送到網(wǎng)上的FAX加密等。

傳統(tǒng)的郵件用戶代理(MUA)可以使用S/MIME來(lái)加密發(fā)1182．協(xié)議結(jié)構(gòu)MIME定義了許多新的RFC822頭域用于描述一個(gè)MIME實(shí)體的內(nèi)容。這些頭域有兩種情形(一種作為常規(guī)RFC822消息頭的一部分，一種是多個(gè)結(jié)構(gòu)中的MIME主體部分頭)。這些正規(guī)頭域的定義如下：entity-headers:=[contentCRLF][encodingCRLF][idCRLF][descriptionCRLF]2．協(xié)議結(jié)構(gòu)119*(MIME-extension-fieldCRLF)MIME-message-headers:=entity-headers[fields]versionCRLF;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.MIME-part-headers:=entity-headers[fields];Anyfieldnotbeginningwith"content-"canhavenodefinedmeaningandmaybeignored.;TheorderingoftheheaderfieldsimpliedbythisBNFdefinitionshouldbeignored.*(