物聯(lián)網(wǎng)信息安全之IPSec和SSL課件

1、物聯(lián)網(wǎng)信息安全之IPSec和SSL1主要內(nèi)容IP安全I(xiàn)P安全性概述IPSec協(xié)議Web安全Web安全概述SSL/TLS協(xié)議2TCP/IP協(xié)議應(yīng)用層HTTP ,SMTP, POP, TELNET, FTP傳輸層TCP,UDP網(wǎng)絡(luò)層IP,ARP,RARP,ICMP,IGMP數(shù)據(jù)鏈路層MAC物理層網(wǎng)卡3 用戶數(shù)據(jù)用戶數(shù)據(jù)應(yīng)用頭應(yīng)用數(shù)據(jù)TCP頭應(yīng)用數(shù)據(jù)TCP頭IP頭應(yīng)用數(shù)據(jù)TCP頭IP頭以太網(wǎng)幀頭TCP分段IP數(shù)據(jù)報(bào)以太網(wǎng)幀142020以太網(wǎng)幀尾446到1500字節(jié)應(yīng)用TCPIP以太網(wǎng)驅(qū)動程序以太網(wǎng)用戶數(shù)據(jù)經(jīng)過協(xié)議棧的封裝過程TCP/IP協(xié)議體系TCP/IP協(xié)議體系是一個開放的協(xié)議平臺，但是缺乏安全性

2、。缺乏對通信雙方身份真實(shí)性的鑒別能力缺乏對傳輸數(shù)據(jù)的完整性和機(jī)密性保護(hù)的機(jī)制由于IP地址可軟件配置以及基于源IP地址的鑒別機(jī)制，IP層存在：業(yè)務(wù)流被監(jiān)聽和捕獲、IP地址欺騙、信息泄露和數(shù)據(jù)項(xiàng)篡改（數(shù)據(jù)完整性的破壞）、身份偽裝、拒絕服務(wù)等攻擊。5Internet安全性途徑應(yīng)用層電子郵件安全協(xié)議(PEM、S/MIME、PGP) 遠(yuǎn)程登陸的安全協(xié)議(SSH) SET、Kerberos、SHTTP傳輸層 SSL / TLS網(wǎng)絡(luò)層IP 安全性(IPSec)6IPSec的起源1994年IETF專門成立IP安全協(xié)議工作組，來制定和推動一套稱為IPSec的IP安全協(xié)議標(biāo)準(zhǔn)。1995年8月公布了一系列關(guān)于IPS

3、ec的建議標(biāo)準(zhǔn)。1996年，IETF公布下一代IP的標(biāo)準(zhǔn)IPv6 ，把鑒別和加密作為必要的特征，IPSec成為其必要的組成部分。1999年底，IETF完成了IPSec擴(kuò)展，在IPSec中加上了ISAKMP（因特網(wǎng)安全關(guān)聯(lián)和密鑰管理協(xié)議），IKE（密鑰交換協(xié)議）和Oakley（密鑰確定協(xié)議）。ISAKMP/IKE/Oakley支持自動建立加密、鑒別信道，以及密鑰的自動安全分發(fā)和更新。幸運(yùn)的是，IPv4也可以實(shí)現(xiàn)這些安全特性。IPSec成為IP層的一部分，在我們的計(jì)算機(jī)中是TCP/IP協(xié)議棧的一部分軟件，它調(diào)用原始IP協(xié)議的功能，被TCP或UDP等協(xié)議調(diào)用。7IPSec概述IPsec提供認(rèn)證（au

4、thentication）：確保收到的數(shù)據(jù)報(bào)是從報(bào)頭中的源端發(fā)出的機(jī)密性（confidentiality）：防止第三方竊聽密鑰協(xié)商（key management）IPSec在IPv6中是強(qiáng)制的，在IPv4中是可選的，這兩種情況下都是采用在主IP報(bào)頭后面接續(xù)擴(kuò)展報(bào)頭的方法實(shí)現(xiàn)的。AH(Authentication Header)是鑒別的擴(kuò)展報(bào)頭ESP header (Encapsulating Security Payload)是實(shí)現(xiàn)加密和鑒別(可選)的擴(kuò)展報(bào)頭8IPSec的應(yīng)用IPSec的主要特征是可以支持IP層所有流量的加密和/或鑒別。因此可以增強(qiáng)所有分布式應(yīng)用的安全性。IPSec為在LAN

5、、WAN和Internet上的通訊提供安全性 分支辦公機(jī)構(gòu)通過Internet互連。(Secure VPN)通過Internet的遠(yuǎn)程訪問。與合作伙伴建立extranet與intranet的互連。增強(qiáng)電子商務(wù)安全性。9IPSec的應(yīng)用方式端到端（end-end):主機(jī)到主機(jī)的安全通信端到路由（end-router):主機(jī)到路由設(shè)備之間的安全通信路由到路由（router-router):路由設(shè)備之間的安全通信，常用于在兩個網(wǎng)絡(luò)之間建立虛擬私有網(wǎng)（VPN）。10一個IP安全的方案11IPSec的優(yōu)點(diǎn)彌補(bǔ)IPv4在協(xié)議設(shè)計(jì)時缺乏安全性考慮的不足。位于傳輸層之下，對應(yīng)用和最終用戶透明。在防火墻或路由器

6、中實(shí)現(xiàn)時，可以防止IP旁路?？梢詫λ锌缭街芙绲牧髁繉?shí)施強(qiáng)安全性。公司或工作組內(nèi)部的通信不會導(dǎo)致招致與安全處理相關(guān)的開銷。需要時IPSec可以提供個人安全性。12四個主要的組成部分：體系結(jié)構(gòu)包括總體概念，安全需求，定義，以及定義IPSec技術(shù)的機(jī)制；認(rèn)證頭（AH）協(xié)議為數(shù)據(jù)包提供身份驗(yàn)證、完整性和抗重播功能，并簽署整個數(shù)據(jù)報(bào)，但不加密該包，因此不提供機(jī)密性。封裝安全載荷（ESP）協(xié)議提供身份驗(yàn)證、完整性、抗重播、機(jī)密性和一定程度的流量保護(hù)。密鑰管理（IKE）協(xié)議用于密鑰交換IPSec13IPSec 體系結(jié)構(gòu)14組成部分說明密鑰管理IKE執(zhí)行兩個階段的操作：密鑰交換和數(shù)據(jù)保護(hù)。通過在彼此通信的計(jì)

7、算機(jī)或網(wǎng)關(guān)上協(xié)商，從而達(dá)成一致的加密和身份驗(yàn)證算法，保證機(jī)密性和身份驗(yàn)證。密鑰安全交換使用DH機(jī)制，可以生成768位或1024位的主密鑰的密鑰材料。加密算法：描述將各種不同加密算法用于ESP的文檔，加密算法有DES、3DES，ESP中強(qiáng)制實(shí)施的加密算法是DES-CBC 。鑒別算法：描述將各種不同鑒別算法用于AH以及ESP鑒別選項(xiàng)的文檔；身份驗(yàn)證方式有Kerberos v5、公鑰證書和預(yù)共享密鑰。完整性算法包括MD5和SHA1。ESP和AH的兩個強(qiáng)制實(shí)施的驗(yàn)證器是HMAC-SHA-96和HMAC-MD5-96。解釋域包括一些參數(shù)，批準(zhǔn)的加密和鑒別算法標(biāo)識，以及運(yùn)行參數(shù)等。15各組成部分說明IPS

8、ec文檔RFC2401： 安全結(jié)構(gòu)概述RFC2402： IP擴(kuò)展的包認(rèn)證概述（IPv4和IPv6）RFC2406： IP擴(kuò)展的包加密描述（IPv4和IPv6）RFC2408： 特定加密機(jī)制 16安全關(guān)聯(lián)SA(Sercurity Association)SA的概念是IPsec的基礎(chǔ)，有的地方也譯為安全聯(lián)盟。SA是發(fā)送與接收者之間對某些要素的一種協(xié)定，如IPsec協(xié)議的使用、協(xié)議的操作模式、密碼算法、密鑰、用于保護(hù)它們之間數(shù)據(jù)流的主密鑰的生存期等。SA安全關(guān)聯(lián)是策略和密鑰的結(jié)合，定義了保護(hù)端到端通信的安全服務(wù)、機(jī)制和密鑰。SA可以看成是兩個IPSec對等端之間的一條隧道，可以為不同類型的流量創(chuàng)建獨(dú)

9、立的SA。比如為TCP創(chuàng)建獨(dú)立的SA，也可以為UDP創(chuàng)建獨(dú)立的SA。SA是單向的，如果需要一個對等關(guān)系，即雙向安全交換，則需要兩個SA。SA提供的具體安全服務(wù)取決于所選的安全協(xié)議（AH或ESP）、模式、SA作用的兩端點(diǎn)和安全協(xié)議所需的服務(wù)。17安全關(guān)聯(lián)SA每個SA通過三個參數(shù)來唯一標(biāo)識 安全參數(shù)索引 (SPI，Security Parameters Index)：一個32位位串，由AH和ESP攜帶，使得接收系統(tǒng)能選擇合適的SA處理接收數(shù)據(jù)報(bào)。對一個單播的SA來說，SPI本身就可確定一個SA，或與IPSec協(xié)議類型一起來確定SA，這是因?yàn)镾PI的值是由接收端產(chǎn)生的，這時SPI是必需的字段；對多播

10、的SA束來說，SPI和可選的IPSec協(xié)議號加上目的地址一起指定一個SA，因?yàn)槎嗖サ腟A束是由一個多播控制器產(chǎn)生而不是IPSec接收者產(chǎn)生，其中1-255之間的SPI值被IANA保留將來使用。IP目的地址：表示SA的目的地址，可以是用戶終端系統(tǒng)、防火墻或路由器。安全協(xié)議標(biāo)識：表示該關(guān)聯(lián)是一個AH安全關(guān)聯(lián)或ESP安全關(guān)聯(lián)。18安全關(guān)聯(lián)SA的管理SA管理的兩大任務(wù)就是SA的創(chuàng)建和刪除SA的管理可以手工進(jìn)行安全參數(shù)由管理員按安全策略手工指定、維護(hù)。容易出錯，手工建立起來的SA沒有生存周期限制。也可以通過IKE完成如果安全策略要求建立安全、保密的連接，但卻不存在相應(yīng)的SA，IPsec的內(nèi)核會自動啟動或

11、觸發(fā)IKE進(jìn)行協(xié)商。19IPsec操作模式IPsec有兩種操作模式傳輸模式（Transport Mode）隧道模式（Tunnel Mode）傳輸模式適用于端主機(jī)的通信，而隧道模式主要用于網(wǎng)關(guān)之間或網(wǎng)關(guān)與主機(jī)之間，也適用于主機(jī)之間的通信。根據(jù)RFC2401的規(guī)定，這兩種模式的區(qū)別是：傳輸模式中僅對上層協(xié)議的報(bào)文提供安全服務(wù)，而IP報(bào)頭是不受保護(hù)的；而隧道模式是對上層協(xié)議和IP報(bào)頭都提供安全服務(wù)。也就是說，兩種模式的實(shí)質(zhì)區(qū)別是對數(shù)據(jù)包保護(hù)的范圍不同。20傳輸模式為上層協(xié)議提供保護(hù)，增加了IP包負(fù)載的保護(hù)。使用原始的明文IP頭，源/目的地址不變，只加密數(shù)據(jù)部分（包括它的TCP和UDP頭），所有安全相

12、關(guān)信息包括在AH和/或ESP頭中。傳輸模式適合于端到端的安全通信。21隧道模式加密整個IP數(shù)據(jù)包包括全部的TCP/IP或UDP/IP頭和數(shù)據(jù)，并用自己的地址作為源地址加入到新的IP頭。當(dāng)通過隧道的數(shù)據(jù)到達(dá)目的網(wǎng)關(guān)（即隧道的另一頭），利用AP和/或ESP頭中的相關(guān)的安全信息對加密過的原IP數(shù)據(jù)報(bào)進(jìn)行處理，將還原的高層數(shù)據(jù)按原IP數(shù)據(jù)報(bào)所標(biāo)明的IP地址遞送，完成真正的源到目的之間的安全傳輸。隧道模式適合于路由到路由或端到路由的安全通信。22IPSec的工作模式然而，在實(shí)際的應(yīng)用中，是對上層數(shù)據(jù)還是對整個數(shù)據(jù)包進(jìn)行保護(hù)，其操作方式、執(zhí)行效率和開銷差別很小。傳輸模式所能達(dá)到的保護(hù)目的，隧道模式也完全可

13、以達(dá)到。雖然在使用隧道模式時因?yàn)橐跀?shù)據(jù)包外層增加一個新IP頭而比傳輸模式多占用一定的帶寬，但可以使用頭部壓縮技術(shù)來解決。IPSec在VPN的應(yīng)用中，由于路由器和網(wǎng)關(guān)的存在，幾乎都是使用隧道模式來保護(hù)數(shù)據(jù)。 23認(rèn)證頭（AH）協(xié)議AH為IP包提供數(shù)據(jù)完整性和認(rèn)證功能，認(rèn)證范圍為整個包，不提供機(jī)密性。利用MAC碼實(shí)現(xiàn)認(rèn)證，雙方必須共享一個密鑰，認(rèn)證算法由SA指定認(rèn)證的范圍：整個包兩種認(rèn)證模式：傳輸模式：不改變IP地址，插入一個AH；隧道模式：生成一個新的IP頭，把AH和原來的整個IP包作為新IP包的載荷。24Next Header：8位，指明AH頭之后的載荷類型，值取自于IANA（The Int

14、ernet Assigned Numbers Authority，互聯(lián)網(wǎng)數(shù)字分配機(jī)構(gòu)）的IP協(xié)議號的定義，如4表明下一個載荷是IPv4，41表示IPv6。Payload Length：8位，以32位字為單位的認(rèn)證數(shù)據(jù)字段的長度。采用以32位的字為單位的值減2。缺省情況下完整性檢查值是一個96位的CRC驗(yàn)證值，再加上3個32位的固定字段，則這個字段的值應(yīng)為4。Reserved：16位，保留SPI：數(shù)據(jù)報(bào)識別SA的32位偽隨機(jī)數(shù)Sequence Number：單調(diào)遞增計(jì)數(shù)值，用來避免重放攻擊Authentication Data：長度可變，但是必須是32位的倍數(shù)，包含針對這個包的完整性校驗(yàn)值（IC

15、V）或者M(jìn)AC。AH認(rèn)證的作用域（IPv4）傳輸模式隧道模式應(yīng)用AH之前26AH認(rèn)證的作用域（IPv6）傳輸模式隧道模式應(yīng)用AH之前27ESP協(xié)議提供保密功能，包括報(bào)文內(nèi)容的機(jī)密性和有限的通信量的機(jī)密性，也可以提供可選的認(rèn)證服務(wù)。將需要保密的IP分組或上層協(xié)議部分（即傳輸層數(shù)據(jù)）封裝到一個ESP載荷中，然后對此載荷進(jìn)行相應(yīng)的安全處理，如進(jìn)行加密、認(rèn)證處理等。ESP只認(rèn)證ESP頭之后的信息。加密算法和認(rèn)證算法由SA指定。兩種工作模式：傳輸模式：將上層協(xié)議部分封裝到ESP載荷之中，采用當(dāng)前的IP頭部。隧道模式：將整個IP封裝到ESP載荷之中，并在ESP頭部添加新的IP頭部，以網(wǎng)關(guān)地址為其源地址。2

16、8ESP協(xié)議數(shù)據(jù)單元由三部分組成頭部加密數(shù)據(jù)可選的尾部ESP加密和認(rèn)證的作用域（IPv4）傳輸模式隧道模式應(yīng)用ESP之前30ESP加密和認(rèn)證的作用域（IPv6）隧道模式應(yīng)用ESP之前傳輸模式31AH和ESP聯(lián)合使用（1）32AH和ESP聯(lián)合使用（2）33IPsec的密鑰管理完成安全參數(shù)的協(xié)商和管理。通過安全關(guān)聯(lián)（SA, Sercurity Association）描述IPSec數(shù)據(jù)封裝的安全參數(shù)。SA創(chuàng)建方式：手工的：通過管理員手動的完成自動的： Internet 密鑰交換協(xié)議 IKE作用：在IPSec通信雙方之間，建立起共享安全參數(shù)及驗(yàn)證過的密鑰（建立“安全關(guān)聯(lián)”），IKE代表IPSec對S

17、A進(jìn)行協(xié)商34IKE協(xié)議（Internet 密鑰交換協(xié)議） IKE用于在兩個通信實(shí)體協(xié)商和建立安全伙伴SA，交換密鑰；IKE包含了3個協(xié)議的有關(guān)部分：ISAKMP、Oakley和SKEME。IKE是在ISAKMP的框架內(nèi)融合使用了部分Oakley和部分SKEME。Oakley和SKEME定義了通信雙方建立共享密鑰必須采取的步驟；ISAKMP(Internet Security Association and Key Management Protocol)框架，是一個針對認(rèn)證和密鑰交換的框架。為正確實(shí)施IKEv1，需遵守三個文檔的規(guī)定：基本ISAKMP規(guī)范（RFC2408）、IPSec解釋域（

18、RFC2407）、IKE規(guī)范本身（RFC2409）。35IKE協(xié)議IPSec 協(xié)議本身沒有提供在通信實(shí)體間建立安全伙伴的方法，利用 IKE 建立安全伙伴。IKE的用途就是在IPSec通信雙方之間，建立起共享安全參數(shù)及驗(yàn)證過的密鑰，亦即建立“安全關(guān)聯(lián)”關(guān)系，并且實(shí)現(xiàn)安全伙伴的集中化管理，減少連接時間。IKE為IPSec通信雙方提供密鑰因子，以用于生成加密密鑰和驗(yàn)證密鑰。另外，IKE也為IPSec協(xié)議AH和ESP協(xié)商SA。IKE協(xié)商的最終結(jié)果：一個通過驗(yàn)證的密鑰，以及建立雙方共享的安全服務(wù)參數(shù)集合（產(chǎn)生IPsec的SA）根據(jù)生成密鑰和保護(hù)對象的不同，IKE協(xié)議的執(zhí)行分成兩個獨(dú)立的階段：第一階段：協(xié)

19、商并創(chuàng)建一個通信信道（IKE SA），對該信道進(jìn)行驗(yàn)證，為雙方進(jìn)一步的IKE通信提供機(jī)密性、消息完整性以及消息源認(rèn)證服務(wù)；第二階段：使用已建立的IKE SA來建立IPsec SA36ISAKMP協(xié)議ISAKMP（Internet Security Association Key Management Protocol，Internet安全聯(lián)盟密鑰管理協(xié)議）由RFC2408定義，定義了協(xié)商、建立、修改和刪除SA的過程和包格式。ISAKMP為SA的屬性和協(xié)商、修改、刪除SA的方法提供了一個通用的框架，但沒有定義具體的SA格式，也沒有定義任何密鑰交換協(xié)議的細(xì)節(jié)或具體的加密算法、密鑰生成技術(shù)、認(rèn)證機(jī)制

20、，它是與密鑰交換獨(dú)立的，可以被不同的密鑰交換協(xié)議使用。ISAKMP報(bào)文可以利用UDP或者TCP，端口都是500，一般情況下常用UDP協(xié)議。ISAKMP雙方交換的內(nèi)容稱為載荷（payload），ISAKMP定義了13種載荷，一個載荷就像積木中的一個“小方塊”，這些載荷按照某種規(guī)則“疊放”在一起，然后在最前面添加上ISAKMP頭部，這樣就組成了一個ISAKMP報(bào)文，這些報(bào)文按照一定的模式進(jìn)行交換，從而完成SA的協(xié)商、修改和刪除等功能。ISAKMP也是IKE中在配置IPSEC VPN的時候唯一可設(shè)置的。ISAKMP定義了交換的包結(jié)構(gòu)。37ISAKMP協(xié)議ISAKMP包含兩個協(xié)商階段，不同階段可以使用

21、不同的密鑰交換協(xié)議定義的交換。階段1為通信雙方建立一個ISAKMP SA，以建立對通信雙方此后的協(xié)商過程的保護(hù)協(xié)定。（IKE SA）階段2中將最終協(xié)商出用于通信雙方正常通信的SA。（IPSec SA）38Oakley協(xié)議Oakley描述了一系列被稱為“模式”的密鑰交換，以及每一種密鑰交換提供的服務(wù)。SKEME（Secure Key Exchange Mechanism，安全密鑰交換機(jī)制）描述了一種提供匿名，抗否認(rèn)，和快速密鑰更新的通用密鑰交換技術(shù)。Oakley和SKEME定義了通信雙方建立共享的驗(yàn)證密鑰所必須采取的步驟和方法，包括：負(fù)載的構(gòu)建；信息負(fù)載的運(yùn)送；信息負(fù)載處理的順序；信息負(fù)載被使用

22、的方法。39IKEv1的身份認(rèn)證方式IKEv1提供4種身份認(rèn)證方式（IKEv2只保留了前兩種）：（1）基于數(shù)字簽名（Digital Signature），利用數(shù)字證書來表示身份，利用數(shù)字簽名算法計(jì)算簽名來驗(yàn)證身份。（2）基于預(yù)共享字符串（PreShared Key），雙方事先通過某種方式商定好一個雙方共享的字符串。（3）基于公開密鑰（Public Key Encryption），利用對方的公開密鑰加密身份，并檢查對方發(fā)來的該HASH值作認(rèn)證。 （4）基于修正的公開密鑰（Revised Public Key Encryption），對方式（3）進(jìn)行修正。IKE使用Diffie-Hellman組中

23、的加密算法，共定義了五個Diffie-Hellman組，其中三個組使用乘冪算法（模長是768、1024、1680位），另兩個組使用橢圓曲線算法（模長是155、185位）。40IKEv1的工作模式IKE定義了4種工作模式：主模式、囂張模式、快速模式、新組模式。前面3個用于協(xié)商SA，最后一個用于協(xié)商Diffie-Hellman算法所用的組。主模式和囂張模式用于第一階段；快速模式用于第二階段；新組模式用于在第一個階段后協(xié)商新的組。41IKEv1的主模式交換的步驟1、策略協(xié)商交換IKE以“保護(hù)組（Protectionsuite）”的形式來定義策略。保護(hù)組至少需定義加密算法（選擇DES或3DES）、散列

24、算法（選擇MD5或SHA）、Diffie-Hellman組以及驗(yàn)證方法（數(shù)字簽名，公共密鑰加密的兩種驗(yàn)證，或者共享密鑰認(rèn)證）。IKE的策略數(shù)據(jù)庫列出了所有保護(hù)組（按各個參數(shù)的順序）。通信雙方?jīng)Q定了一個特定的保護(hù)組后，以后的通信便必須根據(jù)它進(jìn)行。2、Diffie-Hellman共享值、nonce交換交換DH算法生成共享密鑰所需要的基本材料信息。兩端主機(jī)可以各自生成出完全一樣的共享“主密鑰”，保護(hù)緊接其后的認(rèn)證過程。3、身份驗(yàn)證交換對Diffie-Hellman共享秘密進(jìn)行驗(yàn)證，同時還要對IKE_SA本身進(jìn)行驗(yàn)證。“主密鑰”結(jié)合在第一步中確定的協(xié)商算法，對通信實(shí)體和通信信道進(jìn)行認(rèn)證。整個待認(rèn)證的實(shí)

25、體載荷，包括實(shí)體類型、端口號和協(xié)議，均由前一步生成的“主密鑰”提供機(jī)密性和完整性保證?？赡苁褂玫蕉鄠€證書負(fù)載。42IKEv1的主模式交換的步驟 43IKEv1的囂張模式交換的步驟囂張模式（Aggressive mode，也有文獻(xiàn)譯為野蠻模式、主動模式或積極模式）交換也分為三個步驟，但只交換三條消息：頭兩條消息協(xié)商策略，交換Diffie-Hellman公開值必需的輔助數(shù)據(jù)以及身份信息；第二條消息認(rèn)證響應(yīng)方；第三條消息認(rèn)證發(fā)起方，并為發(fā)起方提供在場的證據(jù)。Aggressive模式下，雙方在第一次交換時發(fā)送的身份信息是沒有加密的。Aggressive 模式的優(yōu)點(diǎn)是信息交換快速，但加密被節(jié)省了。44I

26、KEv1的囂張模式交換的步驟 45IKEv1的快速模式交換的步驟第二階段協(xié)商建立IPSec_SA，使用快速模式。快速模式交換的信息必須由IKE SA來保護(hù)，即除了ISAKMP報(bào)頭外，所有的負(fù)載都要加密。HASH負(fù)載和SA負(fù)載必須緊跟在ISAKMP報(bào)頭后。HASH用于驗(yàn)證消息，同時也提供了參與的證據(jù)。快速模式基本上是一次SA協(xié)商和提供重放保護(hù)的nonce交換。nonce用于產(chǎn)生新的密鑰材料并阻止通過重放攻擊產(chǎn)生虛假的安全聯(lián)盟。密鑰交換（KE）負(fù)載是可選的?？焖倌Ｊ浇粨Q通過三條消息建立IPSec_SA：頭兩條消息協(xié)商IPSec_SA的各項(xiàng)參數(shù)值，并生成IPSec 使用的密鑰。包括使用哪種IPSec

27、協(xié)議（AH或ESP）、使用哪種hash算法（D5或SHA）、是否要求加密，若是，選擇加密算法（DES或3DES）。在上述三方面達(dá)成一致后，將建立起兩個SA，分別用于入站和出站通信。第二條消息為響應(yīng)方提供在場的證據(jù)；第三條消息為發(fā)起方提供在場的證據(jù)。46IKEv1的快速模式交換的步驟 47IKEv2IETF組織IP安全工作組于2005年發(fā)布了IKE的新版本，即IKEv2。它整合了IKEvl的相關(guān)RFC文檔，由RFC4306單一文檔定義IKEv2。IKEv2協(xié)議保留了IKEvl的基本功能，同時大幅精簡了原有協(xié)議，在保證安全性的前提下，將第一階段的交互由六條消息簡化為四條，第二階段改為可選，三條消息

28、也變?yōu)閮蓷l。IKEv2還取消了一些在實(shí)際中使用意義不大的概念。IKEvl中，通信雙方的SA生存期必須協(xié)商一致，而IKEv2中雙方可以獨(dú)立選擇SA的生存期。IKEv2每個通用載荷頭部要盡可能保持現(xiàn)有的語法和分配值，盡量兼容IKEvl。IKEv2的所有交互消息以請求/響應(yīng)消息對的形式存在；IKEv2提供超時重傳機(jī)制，發(fā)起方負(fù)責(zé)在等待時間到達(dá)后的消息重傳，響應(yīng)方則不負(fù)責(zé)消息重傳，除非收到對方的重傳請求。IKEv2對IKEvl存在的安全漏洞進(jìn)行了修訂，從抵御中間人攻擊、抵御DoS攻擊、強(qiáng)身份認(rèn)證和完美向前保護(hù)等方面提高了密鑰協(xié)商的安全性。IKEv2支持如擴(kuò)展認(rèn)證協(xié)議EAP、遠(yuǎn)程地址獲取、NAT穿越等新

29、的特性，功能得到了很大的完善。IKEv2取消了模式的概念，不存在“主模式”、“野蠻模式”、“快速模式”、“帶身份保護(hù)的主模式”和“新組模式”等交換類型。48IKEv2IKEv2協(xié)商SA分為兩步實(shí)現(xiàn)：首先，在通信雙方間建立經(jīng)認(rèn)證的安全信道IKE_SA；然后，在IKE_SA保護(hù)下建立CHILD_SA，即IKEvl中的IPSec_SA。49IKEv2IKEv2中的消息交換包括三種基本交換類型：初始交換（Initial Exchange）、協(xié)商子SA交換（CREATE_CHILD_SA Exchange）信息交換（Informational Exchange）。IKEv2的初始交換對應(yīng)IKEvl的第一

30、階段交換， 即IKE_SA階段，包含兩個步驟：IKE_SA_INIT和IKE_AUTH，由四條消息構(gòu)成。IKE_SA_INIT的一對消息用來協(xié)商加密算法，交換nonce值，以進(jìn)行Diffie_Hellman交換計(jì)算，并得到后續(xù)各種密鑰值。IKE_AUTH的一對消息用于雙方認(rèn)證，并交換身份和證書（可選）、確定流量選擇符。此輪交互用于建立首個CHILD_SA。如果只需要一個CHILD_SA，則無需進(jìn)行子SA協(xié)商交換。50IKEv2的初始交換HDR是IKE頭，包括：版本號、SPIi（發(fā)起者給出的SA標(biāo)識）；SAi1是發(fā)起者支持IKE_SA的密碼算法集，包括DH組、加密、認(rèn)證算法；KEi和KEr是Di

31、ffie-Hellman值；Ni和Nr是Nonce值；SAr1是響應(yīng)方在SAi1內(nèi)選擇的算法；CERTREQ是可選的，指請求首選CA，表示應(yīng)答方要求使用數(shù)字證書認(rèn)證；表示載荷受SK_e、SK_a和IKE 加密和認(rèn)證算法進(jìn)行加密和完整性保護(hù)；IDi, IDr用于認(rèn)證，它基于預(yù)共享秘鑰SK_pi, SK_pr；Auth是預(yù)共享秘鑰 (SK_pi, SK_pr) + ID或數(shù)字證書；SAi2和SAr2 用于生成CREATE_CHILD_SA；TS標(biāo)明被SAi2, SAr2所保護(hù)的傳輸層參數(shù)（協(xié)議、端口范圍和地址范圍），如TSi = (0, 0-65535,02-02)，TSr = (0, 0-655

32、35,-55) 51IKEv2IKEv2在IKE_SA_INIT中計(jì)算出密鑰種子SKEYSEED。SKEYSEED = prf（Ni | Nr，gir），prf是偽隨機(jī)函數(shù)。SKEYSEED用來繼續(xù)生成其它7個密鑰材料：SK_d用來生成CHILD_SA的密鑰，發(fā)起方和響應(yīng)方共享SK_d；SK_ai和SK_ar用于驗(yàn)證；SK_ei和SK_er用于加解密；SK_pi和SK_pr用來生成AUTH載荷。它們的生成方法為：SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr = Prf+（SKEYSEED，Ni | Nr | SPIi | SPIr）其

33、中，prf+ 函數(shù)如下定義：prf+（K,S） = T1 , T2 , T3 , T4 , .，T1 = prf （K, S | 0 x01）T2 = prf （K, T1 | S | 0 x02）T3 = prf （K, T2 | S | 0 x03）T4 = prf （K, T3 | S | 0 x04） ，依次類推，| 表示連接。52IKEv2CHILD_SA密鑰材料生成方式如下：KEYMAT = Prf+（SK_d，Ni | Nr）對于使用PFS的CREATE_CHILD_SA交換，密鑰材料定義如下：KEYMAT = Prf+（SK_d，gir | Ni | Nr）。其中g(shù)ir取自于C

34、REATE_CHILD_SA交換中的DH交換，gir = gS_i*S_r，S_i和S_r是雙方的私鑰。IKEv2支持兩種認(rèn)證方法：數(shù)字簽名和預(yù)共享密鑰。當(dāng)消息2中附有CERTREQ載荷時表示使用數(shù)字簽名認(rèn)證。數(shù)字簽名認(rèn)證需要雙方的消息提供證書CERT。發(fā)起者對附有Nr和prf(SK_ai, IDi)的第一條消息進(jìn)行簽名；響應(yīng)者對附有Ni 和prf(SK_ar, IDr)的第二條消息進(jìn)行簽名。預(yù)共享密鑰是 (SK_pi, SK_pr)，HMAC 使用協(xié)商的prf函數(shù)，AUTH = prf(prf(Shared Secret, Key Pad for IKEv2), )53IKEv2子SA協(xié)商交

35、換（CREATE_CHILD_SA Exchange）在響應(yīng)方發(fā)現(xiàn)自己受到DoS攻擊的情況下，可再進(jìn)行子SA交換協(xié)商。該交換對應(yīng)著IKEvl的第二階段交換，用于建立新的CHILD_SA，由交互雙方中生存期到期的一方發(fā)起。其中兩條消息使用初始交換中選擇的加密和認(rèn)證算法保護(hù)消息。54IKEv2N是新SA的協(xié)商標(biāo)識；KEx是可選的Diffie-Hellman 值，需對CHILD_SA的PFS（完美前向秘密性，指獲取某個會話密鑰不會連累其它會話密鑰，任何密鑰都不能從以前的密鑰中推導(dǎo)出來）進(jìn)行保護(hù)時存在，用于計(jì)算新的IPSec 密鑰，應(yīng)與上一階段的不同； TSx：當(dāng)N存在時用于新IPSec_SA的重新協(xié)

36、商；SK 函數(shù)由之前協(xié)商的IKE_SA保護(hù)，IKE_SA可用于生成很多IPSec_SA，因此IKE_SA可使用較長時間；Ni 和 Nr是Nonce，應(yīng)與上一階段的不同。55IKEv2生成CHILD_SA后，IPSec中的AH 或 ESP所需的密鑰就可以產(chǎn)生了，密鑰材料：KEYMAT = prf+(SK_d, Ni | Nr)，其中Ni 和 Nr 是該階段的新nonce；需提供FPS保護(hù)時：KEYMAT = prf+(SK_d, gs_i* s_r | Ni | Nr ) ；其中s_i 和s_r 是階段2中的新DH值，SK_d 是第一階段生成的。若要生成256位的AES密鑰，需將160位的prt

37、+ 函數(shù)運(yùn)行兩次。56IPSec的討論雖然到目前為止，全球安全專家普遍認(rèn)為IPSec是最安全的IP協(xié)議，但也并非全是贊美之詞，最主要的批評是它的復(fù)雜性。57IP安全I(xiàn)P安全性概述IPSec協(xié)議Web安全Web安全概述SSL/TLS協(xié)議主要內(nèi)容58Web安全Web是一個運(yùn)行于internet和TCP/IP intranet 之上的基本的client/server應(yīng)用。Web安全性涉及前面討論的所有計(jì)算機(jī)與網(wǎng)絡(luò)的安全性內(nèi)容。同時還具有新的挑戰(zhàn)。59Web的安全需求Internet是雙向的。Web對于Internet上針對Web服務(wù)器的攻擊是非常脆弱的。Web越來越多地作為公司和產(chǎn)品信息的高度可視化

38、的窗口和商業(yè)交互的平臺。如果Web服務(wù)器被破壞，聲譽(yù)可能被損害，經(jīng)濟(jì)會受到損失。盡管Web瀏覽器非常容易使用，Web服務(wù)器相對容易配置和管理，Web內(nèi)容也越來越容易開發(fā)，但底層的軟件卻異乎尋常的復(fù)雜。這個復(fù)雜的軟件可能隱藏了很多潛在的安全隱患。Web服務(wù)器可以被使用成進(jìn)入公司或機(jī)構(gòu)整個計(jì)算機(jī)系統(tǒng)的發(fā)射臺。一旦Web服務(wù)器被破壞，攻擊者可以訪問不是Web一部分的而是連接到本地站點(diǎn)服務(wù)器上的數(shù)據(jù)和系統(tǒng)。不經(jīng)意的和沒有經(jīng)過訓(xùn)練的用戶（從安全的角度來看）是基于Web服務(wù)的常見客戶。這樣的用戶并不是必須了解存在的安全風(fēng)險，并且也沒有工具或知識采取有效的對策。60Web所面臨的安全威脅威脅后果對策完整性修

39、改用戶數(shù)據(jù)特洛伊木馬瀏覽器對存儲器的修改修改傳輸中的報(bào)文通信量信息丟失危及機(jī)器的安全容易受到其他所有威脅的攻擊加密的檢驗(yàn)和機(jī)密性在網(wǎng)上竊聽從服務(wù)器上偷竊信息從客戶那里偷竊數(shù)據(jù)有關(guān)網(wǎng)絡(luò)配置的信息有關(guān)哪個客戶與服務(wù)器交談的信息信息丟失丟失秘密加密，Web代理（proxy）拒絕服務(wù)破壞用戶線程用假的請求來淹沒機(jī)器填滿硬盤或存儲器通過DNS攻擊來孤立機(jī)器破壞性的騷擾性的阻止用戶完成工作防治起來很困難鑒別扮演合法用戶數(shù)據(jù)偽造誤傳用戶相信假信息是合法的加密技術(shù)按主動和被動攻擊分類主動攻擊包括假扮另一個用戶，修改客戶與服務(wù)器之間傳輸?shù)男畔?，或修改一個Web站點(diǎn)的信息。被動攻擊包括偷聽測覽器和服務(wù)器之間的網(wǎng)絡(luò)

40、通信量，獲得對于Web站點(diǎn)受限制的信息的訪問權(quán)。按位置分類服務(wù)器和瀏覽器的安全，屬于計(jì)算機(jī)系統(tǒng)安全性的范疇。瀏覽器與服務(wù)器之間的網(wǎng)絡(luò)通信量，屬于網(wǎng)絡(luò)安全的范疇。對Web安全威脅的分類62實(shí)現(xiàn)Web通信量安全性的方法網(wǎng)絡(luò)級：在IP層實(shí)現(xiàn)，常用的是IPSec。此方法對于最終用戶和應(yīng)用程序來說是透明的，并且提供了通用的解決方法。傳輸級：TCP上實(shí)現(xiàn)，常用的是SSL/TLS。為了達(dá)到完全通用，SSL/TLS可以作為基本協(xié)議族的一個部分提供，因而對于應(yīng)用程序是透明的。也可以將SSL嵌入到專門的軟件包中，例如許多瀏覽器都配置了SSL，大多數(shù)Web服務(wù)器也已經(jīng)實(shí)現(xiàn)了這個協(xié)議。應(yīng)用級：與應(yīng)用有關(guān)的安全服務(wù)被嵌

41、入到特定的應(yīng)用程序中。對于Web安全而言，這種方法的一個重要例子是SET。 UDP HTTP FTP SMTP TCP IP / IPSecHTTP FTP SMTP TCP IP SSL TLS S/MIME PGP SET TCP IP HTTP SMTP Kerberos (a)網(wǎng)絡(luò)級 (b)傳輸級 (c)應(yīng)用級 SSL/TLS協(xié)議SSL（Secure socket layer）協(xié)議已成為網(wǎng)絡(luò)用來鑒別網(wǎng)站和網(wǎng)頁瀏覽者身份，以及在瀏覽器使用者及網(wǎng)頁服務(wù)器之間進(jìn)行加密通訊的全球化標(biāo)準(zhǔn)。由于SSL技術(shù)已建立到所有主要的瀏覽器和WEB服務(wù)器程序中，因此，僅需安裝數(shù)字證書，或服務(wù)器證書就可以激活服

42、務(wù)器功能了。SSL是介于HTTP和TCP之間的一個可選層。SSL層在TCP層之上建立了一個加密通道，通過這一層的數(shù)據(jù)經(jīng)過了加密，因此達(dá)到了保密的效果。SSL層借助下層協(xié)議的信道安全協(xié)商出一份加密密鑰，并用此密鑰來加密HTTP請求；而TCP層與Web Server的443端口建立連接，傳遞SSL處理后的數(shù)據(jù)。64SSL/TLS協(xié)議1994年Netscape開發(fā)了SSL(Secure Socket Layer)安全套接層協(xié)議，專門用于保護(hù)Web通訊。IETF（）將SSL作了標(biāo)準(zhǔn)化，即RFC2246，并將其稱為TLS（Transport Layer Security）。版本和歷史1.0，不成熟2.0

43、，基本上解決了Web通訊的安全問題3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷TLS 1.0(Transport Layer Security傳輸層安全協(xié)議, 也被稱為SSL 3.1)，1997年IETF發(fā)布了Draft1999年，發(fā)布RFC 2246(The TLS Protocol v1.0)65SSL協(xié)議SSL協(xié)議的目標(biāo)：SSL被設(shè)計(jì)用來使用TCP提供一個可靠的端到端安全服務(wù)，為兩個通訊個體之間提供保密性、完整性和合法性認(rèn)證(身份鑒別)。SSL協(xié)議的作用：解決如下問題客戶對服務(wù)器的身份確認(rèn)服務(wù)器對客戶的身份確認(rèn)建立起服務(wù)器和客戶之間安全的數(shù)據(jù)通道66SSL的體系結(jié)構(gòu)SSL不是單

44、個協(xié)議，而是兩層協(xié)議。底層：SSL記錄協(xié)議。為不同的更高層協(xié)議提供了基本的安全服務(wù)。上層：握手協(xié)議、修改密文規(guī)約協(xié)議和告警協(xié)議。用于管理SSL交換。67SSL記錄協(xié)議和SSL握手協(xié)議SSL記錄協(xié)議建立在可靠的傳輸協(xié)議(如TCP)之上它提供連接安全性，有兩個特點(diǎn)保密性，使用了對稱加密算法完整性，使用HMAC算法用來封裝高層的協(xié)議SSL握手協(xié)議客戶和服務(wù)器之間相互鑒別協(xié)商加密算法和密鑰它提供連接安全性，有三個特點(diǎn)身份鑒別，至少對一方實(shí)現(xiàn)鑒別，也可以是雙向鑒別協(xié)商得到的共享密鑰是安全的，中間人不能夠知道協(xié)商過程是可靠的68SSL連接和SSL會話SSL連接（Connection）：連接是提供恰當(dāng)類型服

45、務(wù)的傳輸（在OSI分層模型的定義中）。對于SSL，這樣的連接是點(diǎn)對點(diǎn)的關(guān)系。連接是短暫的，每個連接與一個會話相聯(lián)系。SSL會話（Session）：一個SSL的會話是客戶和服務(wù)器之間的一個關(guān)聯(lián)，會話通過握手協(xié)議來創(chuàng)建。會話定義了加密安全參數(shù)的一個集合，該集合可以被多個連接所共享。會話可以用來避免為每個連接進(jìn)行昂貴的新安全參數(shù)的協(xié)商。69SSL會話狀態(tài)參數(shù)會話標(biāo)識符：服務(wù)器選擇的任意字節(jié)序列，用來標(biāo)識活動的或可恢復(fù)的會話狀態(tài)。對方的證書：對方的X.509 v3證書。狀態(tài)的這個元素可以為空。壓縮方法：在加密之前用來壓縮數(shù)據(jù)的算法。密文規(guī)約（Cipher spec）：指明大塊數(shù)據(jù)加密算法（例如，空、D

46、ES等等），用于MAC計(jì)算的散列算法（例如 MD5或 SHA-l）。它還定義了加密屬性，例如hash_size。主密碼：48個字節(jié)長的客戶和服務(wù)器共享的密碼?？苫謴?fù)性：指示會話是否可以用來初始化新的連接的標(biāo)志。 70SSL連接狀態(tài)參數(shù)服務(wù)器和客戶的隨機(jī)數(shù)：服務(wù)器和客戶為每個連接選擇的字節(jié)序列。服務(wù)器寫MAC密碼：用于對服務(wù)器發(fā)送數(shù)據(jù)進(jìn)行MAC操作的密鑰?？蛻魧慚AC密碼：用于對客戶發(fā)送數(shù)據(jù)進(jìn)行MAC操作的密鑰。服務(wù)器寫密鑰：用于服務(wù)器對數(shù)據(jù)加密和客戶對數(shù)據(jù)解密的常規(guī)加密密鑰?？蛻魧懨荑€：用于客戶對數(shù)據(jù)加密和服務(wù)器對數(shù)據(jù)解密的常規(guī)加密密鑰。初始化向量：當(dāng)使用CBC模式的分組密文時，為每個密鑰維護(hù)

47、的初始化向量。這個字段首先被SSL握手協(xié)議初始化。然后每個記錄最終的密文塊被保留下來作為下一個記錄的IV。序號：每一方為每個連接的傳輸和接收報(bào)文維持著單獨(dú)的序號。當(dāng)一方發(fā)送和接收修改密文規(guī)約報(bào)文時，相應(yīng)的序號被設(shè)置成0。序號不能超過264 - 1。71SSL/TLS協(xié)議SSL本身是一個分層協(xié)議，每一層的消息塊都包含有長度、描述和內(nèi)容。SSL協(xié)議的記錄協(xié)議層在客戶機(jī)和服務(wù)器之間傳輸應(yīng)用數(shù)據(jù)和SSL控制數(shù)據(jù)，即用于交換應(yīng)用數(shù)據(jù)，包括了記錄頭和記錄數(shù)據(jù)格式的規(guī)定。應(yīng)用程序消息被分割成可管理的數(shù)據(jù)塊，還可以壓縮，并產(chǎn)生一個MAC（消息認(rèn)證代碼），然后將結(jié)果加密并傳輸。接收方接受數(shù)據(jù)并對它解密，校驗(yàn)MA

48、C，解壓并重新組合，再把結(jié)果提供給應(yīng)用程序協(xié)議。所有的SSL通信，包括握手消息、安全空白記錄和應(yīng)用數(shù)據(jù)都使用SSL記錄層。SSL中，所有的傳輸數(shù)據(jù)都被封裝在記錄中。記錄由記錄頭和長度不為0的記錄數(shù)據(jù)組成。SSL的記錄數(shù)據(jù)包含三個部分：MAC數(shù)據(jù)、實(shí)際數(shù)據(jù)和粘貼數(shù)據(jù)。72SSL記錄協(xié)議SSL記錄層協(xié)議限定了所有發(fā)送和接收數(shù)據(jù)的打包，它提供了通信、身份認(rèn)證功能，它是一個在面向連接的可靠傳輸協(xié)議。SSL記錄協(xié)議為SSL連接提供兩種服務(wù)。保密性。消息完整性。73SSL記錄協(xié)議操作過程發(fā)送：記錄協(xié)議接收傳輸?shù)膽?yīng)用報(bào)文，將數(shù)據(jù)分片成可管理的塊，可選地壓縮數(shù)據(jù)，應(yīng)用MAC，加密，增加首部，在TCP報(bào)文段中傳

49、輸結(jié)果單元。接收：被接收的數(shù)據(jù)被解密、驗(yàn)證、解壓和重新裝配，然后交付給更高級的用戶。74SSL記錄協(xié)議操作過程 75SSL記錄格式在SSL中，所有數(shù)據(jù)被封裝在記錄中。一個記錄由兩部分組成：記錄頭和非零長度的數(shù)據(jù)。SSL的上層協(xié)議，即管理協(xié)議的報(bào)文只可放在一個SSL記錄層的記錄里，但應(yīng)用層協(xié)議的報(bào)文允許占用多個SSL記錄來傳送。SSL記錄的格式如下：76SSL記錄協(xié)議首部構(gòu)成內(nèi)容類型（8比特）：用來處理這個包裝的數(shù)據(jù)片的更高層協(xié)議。已經(jīng)定義的內(nèi)容類型是修改密碼規(guī)約、告警、握手和應(yīng)用數(shù)據(jù)。前三個是與SSL有關(guān)的協(xié)議。主要版本（8比特）：指示使用SSL的主要版本。對于SSLv3，字段值為3。次要版本

50、（8比特）：指示使用的次要版本。對于SSLv3，字段值為0。長度（16比特）：數(shù)據(jù)片以字節(jié)為單位的長度（明文數(shù)據(jù)片長度不超過214，壓縮數(shù)據(jù)片長度不超過214+1024，密文數(shù)據(jù)片長度不超過214+2048）。SSL記錄格式77SSL修改密碼規(guī)約協(xié)議這個協(xié)議由單個報(bào)文組成，該報(bào)文由值為1的單個字節(jié)組成。這個報(bào)文雙方都可以發(fā)起，目的是表示從下一個記錄開始，使用新的密碼規(guī)約。78SSL告警協(xié)議告警協(xié)議是用來將SSL有關(guān)的告警傳送給對方實(shí)體。和其他使用SSL的應(yīng)用一樣，告警報(bào)文按照當(dāng)前狀態(tài)說明被壓縮和加密。這個協(xié)議的每個報(bào)文由兩個字節(jié)組成。第一個字節(jié)的值是警告（warning）（1）或致命（fata

51、l）（2），用來傳送報(bào)文的嚴(yán)重級別。如果級別是致命的，SSL立刻中止該連接。同一個會話的其他連接可以繼續(xù)，但是這個會話不可以再建立新的連接了。第二個字節(jié)包含了指出特定告警的代碼。79SSL握手協(xié)議SSL握手協(xié)議由客戶端和服務(wù)器間交換的一系列消息組成，消息格式如下圖所示。類型（1字節(jié)）：指示10種消息中的一個。 長度（3字節(jié)）：以字節(jié)為單位的報(bào)文長度。內(nèi)容（0字節(jié)）：和這個報(bào)文有關(guān)的參數(shù) 。80SSL握手協(xié)議使用的消息報(bào)文類型參數(shù)hello_request空client_hello版本、隨機(jī)數(shù)、會話 ID、密文族、壓縮方法server_hello版本、隨機(jī)數(shù)、會話ID、密文族、壓縮方法certi

52、ficateX509 v3證書鏈server_key_exchange參數(shù)、簽名certificate_request類型、授權(quán)server_done空certificate_verify簽名client_key_exchange參數(shù)、簽名finished散列值81SSL握手協(xié)議的流程 客戶 服務(wù)器 建立安全能力，包括協(xié)議版本、會話ID、密碼簇、壓縮方法和初始隨機(jī)數(shù) 服務(wù)器可以發(fā)送證書、密鑰交換和證書請求。服務(wù)器發(fā)出結(jié)束hello報(bào)文階段的信號 如果請求的話，客戶發(fā)送證書，客戶發(fā)送密鑰交換，客戶可以發(fā)送證書驗(yàn)證報(bào)文 修正密碼簇并結(jié)束握手協(xié)議 client_hello server_hello

53、certificate server_key_exchange certificate_request server_hello_done certificate client_key_exchange certificate_verify change_cipher_spec finished change_cipher_spec finished 時間 第一階段：建立起安全協(xié)商客戶發(fā)送一個client_hello消息，包括以下參數(shù)：版本、隨機(jī)數(shù)(32位時間戳+28字節(jié)隨機(jī)序列)、會話ID、客戶支持的密碼算法列表(CipherSuite)、客戶支持的壓縮方法列表然后，客戶等待服務(wù)器的serv

54、er_hello消息服務(wù)器發(fā)送server_hello消息，參數(shù)：客戶建議的低版本以及服務(wù)器支持的最高版本、服務(wù)器產(chǎn)生的隨機(jī)數(shù)、會話ID、服務(wù)器從客戶建議的密碼算法中選出的密碼組、服務(wù)器從客戶建議的壓縮方法中選出的一個壓縮算法83密碼組參數(shù)說明密碼組參數(shù)的第一個元素指定了密鑰交換的方法，SSL支持以下一些方法：RSA，要求服務(wù)器提供一個RSA證書DH(Diffie-Hellman)，要求服務(wù)器的證書中包含了由CA簽名的DH公開參數(shù)?？蛻艋蛘咴谧C書中提供DH公開參數(shù)，或者在密鑰交換消息中提供此參數(shù)瞬時DH(Ephemeral Diffie-Hellman)，產(chǎn)生臨時的密鑰，DH公開參數(shù)由發(fā)送者的

55、私鑰進(jìn)行簽名，接收者用對應(yīng)的公鑰進(jìn)行驗(yàn)證匿名的DH，不加鑒別。會受到中間人攻擊然后，指定以下信息加密算法，和類型(流還是分組密碼算法)MAC算法，MD5還是SHA-1HashSizeKey MaterialIV Size84第二階段：服務(wù)器鑒別和密鑰交換服務(wù)器發(fā)送自己的證書，消息包含一個X.509證書，或者一條證書鏈除了匿名DH之外的密鑰交換方法都需要服務(wù)器發(fā)送server_key_exchange消息可選的，有些情況下可以不需要。只有當(dāng)服務(wù)器的證書沒有包含必需的數(shù)據(jù)的時候才發(fā)送此消息消息包含簽名，被簽名的內(nèi)容包括兩個隨機(jī)數(shù)以及服務(wù)器參數(shù)服務(wù)器發(fā)送certificate_request消息非匿

56、名server可以向客戶請求一個證書包含證書類型和CAs服務(wù)器發(fā)送server_hello_done, 然后等待應(yīng)答85第三階段：客戶鑒別和密鑰交換客戶收到server_done消息后，它根據(jù)需要檢查服務(wù)器提供的證書，并判斷server_hello的參數(shù)是否可以接受，如果都沒有問題的話，發(fā)送一個或多個消息給服務(wù)器如果服務(wù)器請求證書的話，則客戶首先發(fā)送一個certificate消息，若客戶沒有證書，則發(fā)送一個no_certificate警告然后客戶發(fā)送client_key_exchange消息，消息的內(nèi)容取決于密鑰交換的類型最后，客戶發(fā)送一個certificate_verify消息，其中包含一個

57、簽名，對從第一條消息以來的所有握手消息的HMAC值(用master_secret)進(jìn)行簽名86第四階段：結(jié)束第四階段建立起一個安全的連接客戶發(fā)送一個change_cipher_spec消息，并且把協(xié)商得到的CipherSuite拷貝到當(dāng)前連接的狀態(tài)之中然后，客戶用新的算法、密鑰參數(shù)發(fā)送一個finished消息，這條消息可以檢查密鑰交換和鑒別過程是否已經(jīng)成功。其中包括一個校驗(yàn)值，對所有的消息進(jìn)行校驗(yàn)。服務(wù)器同樣發(fā)送change_cipher_spec消息和finished消息。握手過程完成，客戶和服務(wù)器可以交換應(yīng)用層數(shù)據(jù)。87過程回顧 客戶方CH（Client Hello）消息客戶方證書*CKE

58、（Client Key Exchange）消息DSCV（ digitally-signed certificate verify）消息*CCS（change cipher spec）消息CHF（Client HandShaking Finished）消息服務(wù)方SH（Server Heelo）消息服務(wù)方證書*客戶方證書請求消息*SKE（Server Key Exchange）消息*CCS（change cipher spec）消息SHF（Server HandShaking Finished）消息應(yīng)用層數(shù)據(jù)應(yīng)用層數(shù)據(jù)88SSL協(xié)議采用的加密算法和認(rèn)證算法加密算法和會話密鑰SSL協(xié)議V2和V3支持的加密算法包括RC4、RC2、IDEA和DES而