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

第六章平安套接層協(xié)議SSLSSL概述SSL體系結(jié)構(gòu)與協(xié)議SSL協(xié)議的平安性分析SSL的應(yīng)用目前國(guó)際上流行的電子商務(wù)所采用的協(xié)議主要有：平安套接層協(xié)議〔SecureSockets

Layer，SSL〕基于信用卡交易的平安電子協(xié)議〔SecureElectronicTransaction，SET〕平安HTTP〔S-HTTP〕協(xié)議平安電子郵件協(xié)議〔PEM、S/MIME等〕用于公對(duì)公交易的InternetEDI等。此外在Internet網(wǎng)上利用Ipsec標(biāo)準(zhǔn)建設(shè)虛擬專(zhuān)用網(wǎng)，利用VPN為企業(yè)、政府提供一些根本的平安效勞，6.1SSL概述SSL協(xié)議是一種國(guó)際標(biāo)準(zhǔn)的加密及身份認(rèn)證通信協(xié)議目標(biāo)：SSL被設(shè)計(jì)用來(lái)使用TCP提供一個(gè)可靠的端到端平安效勞，為兩個(gè)通訊個(gè)體之間提供保密性和完整性(身份鑒別)。SSL/TLS協(xié)議1994年Netscape開(kāi)發(fā)了SSL(SecureSocketLayer)平安套接層協(xié)議，專(zhuān)門(mén)用于保護(hù)Web通訊版本和歷史1.0，不成熟2.0，根本上解決了Web通訊的平安問(wèn)題Microsoft公司發(fā)布了PCT(PrivateCommunicationTechnology)，并在IE中支持3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷TLS1.0(TransportLayerSecurity傳輸層平安協(xié)議,也被稱(chēng)為SSL3.1)，1997年IETF發(fā)布了Draft，同時(shí)，Microsoft宣布放棄PCT，與Netscape一起支持TLS1.01999年，發(fā)布RFC2246(TheTLSProtocolv1.0)協(xié)議的使用s://與s://在網(wǎng)絡(luò)上傳輸?shù)拿舾行畔ⅰ踩珉娮由虅?wù)、金融業(yè)務(wù)中的信用卡號(hào)或PIN碼等機(jī)密信息〕都紛紛采用SSL來(lái)進(jìn)行平安保護(hù)。SSL通過(guò)加密傳輸來(lái)確保數(shù)據(jù)的機(jī)密性，通過(guò)信息驗(yàn)證碼〔MessageAuthenticationCodes，MAC〕機(jī)制來(lái)保護(hù)信息的完整性，通過(guò)數(shù)字證書(shū)來(lái)對(duì)發(fā)送和接收者的身份進(jìn)行認(rèn)證。IP/IPSecTCPLowerlayersIPTCPLowerlayersSSLOSIPSecSSL一個(gè)保證任何安裝了平安套接字的客戶(hù)和效勞器間事務(wù)平安的協(xié)議，它涉及所有TCP/IP應(yīng)用程序SSL協(xié)議可用于保護(hù)正常運(yùn)行于TCP之上的任何應(yīng)用協(xié)議，如HTTP、FTP、SMTP或Telnet的通信，最常見(jiàn)的是用SSL來(lái)保護(hù)HTTP的通信。SSL協(xié)議的優(yōu)點(diǎn)在于它是與應(yīng)用層協(xié)議無(wú)關(guān)的。高層的應(yīng)用協(xié)議〔如HTTP、FTP、Telnet等〕能透明地建立于SSL協(xié)議之上。SSL協(xié)議在應(yīng)用層協(xié)議之前就已經(jīng)完成加密算法、通信密鑰的協(xié)商以及效勞器的認(rèn)證工作。在此之后應(yīng)用層協(xié)議所傳送的數(shù)據(jù)都會(huì)被加密，從而保證通信的平安性。SSL協(xié)議使用通信雙方的客戶(hù)證書(shū)以及CA根證書(shū)，允許客戶(hù)/效勞器應(yīng)用以一種不能被偷聽(tīng)的方式通信，在通信雙方間建立起了一條平安的、可信任的通信通道。該協(xié)議使用密鑰對(duì)傳送數(shù)據(jù)加密，許多網(wǎng)站都是通過(guò)這種協(xié)議從客戶(hù)端接收信用卡編號(hào)等保密信息。它被認(rèn)為是最平安的在線交易模式，SSL解決的問(wèn)題〔功能〕客戶(hù)對(duì)效勞器的身份認(rèn)證SSL效勞器允許客戶(hù)的瀏覽器使用標(biāo)準(zhǔn)的公鑰加密技術(shù)和一些可靠的認(rèn)證中心〔CA〕的證書(shū)，來(lái)確認(rèn)效勞器的合法性。效勞器對(duì)客戶(hù)的身份認(rèn)證也可通過(guò)公鑰技術(shù)和證書(shū)進(jìn)行認(rèn)證，也可通過(guò)用戶(hù)名，password來(lái)認(rèn)證。建立效勞器與客戶(hù)之間平安的數(shù)據(jù)通道SSL要求客戶(hù)與效勞器之間的所有發(fā)送的數(shù)據(jù)都被發(fā)送端加密、接收端解密，同時(shí)還檢查數(shù)據(jù)的完整性SSL提供的平安效勞用戶(hù)和效勞器的合法性認(rèn)證usingX.509v3digitalcertificates傳輸數(shù)據(jù)的機(jī)密性u(píng)singoneofDES,TripleDES,IDEA,RC2,RC4,…傳輸數(shù)據(jù)的完整性u(píng)singMACwithMD5orSHA-1SSL協(xié)議實(shí)現(xiàn)的六步驟

⑴接通階段：客戶(hù)機(jī)通過(guò)網(wǎng)絡(luò)向效勞器打招呼，效勞器回應(yīng)；⑵密碼交換階段：客戶(hù)機(jī)與效勞器之間交換雙方認(rèn)可的密碼，一般選用RSA密碼算法；

⑶會(huì)談密碼階段：客戶(hù)機(jī)器與效勞器間產(chǎn)生彼此交談的會(huì)談密碼；⑷檢驗(yàn)階段：客戶(hù)機(jī)檢驗(yàn)效勞器取得的密碼；⑸客戶(hù)認(rèn)證階段：效勞器驗(yàn)證客戶(hù)機(jī)的可信度；⑹結(jié)束階段：客戶(hù)機(jī)與效勞器之間相互交換結(jié)束的信息。6.1.3SSL協(xié)議與電子商務(wù)SSL提供了用于啟動(dòng)TCP/IP連接的平安性“信號(hào)交換〞。這種信號(hào)交換導(dǎo)致客戶(hù)和效勞器同意將使用的平安性級(jí)別，并履行連接的任何身份驗(yàn)證要求。通過(guò)數(shù)字簽名和數(shù)字證書(shū)可實(shí)現(xiàn)瀏覽器和Web效勞器雙方的身份驗(yàn)證。在用數(shù)字證書(shū)對(duì)雙方的身份驗(yàn)證后，雙方就可以用保密密鑰進(jìn)行平安的會(huì)話(huà)了。SSL證書(shū)保障在線效勞器的平安效勞器身份驗(yàn)證——防假冒網(wǎng)絡(luò)信息發(fā)送內(nèi)容加密——防偷窺網(wǎng)絡(luò)信息發(fā)送完整性檢測(cè)——防刪節(jié)網(wǎng)絡(luò)信息發(fā)送內(nèi)容修改提醒——防篡改應(yīng)用數(shù)據(jù)改變密碼套，結(jié)束握手送出客戶(hù)端證書(shū)送出效勞器證書(shū)，請(qǐng)求客戶(hù)端證書(shū)SSL流程瀏覽器Web效勞器SSL平安通道客戶(hù)端證書(shū)效勞器證書(shū)ClienthelloServerhelloServerCertificateCertificateRequestServerKeyExchangeClientCertificateClientKeyExchangeCertificateVerifyChangeCipherSpecFinishedChangeCipherSpecFinishedApplicationDataApplicationData建立協(xié)議版本、會(huì)話(huà)ID、交換隨機(jī)數(shù)SSL效勞器證書(shū)工作原理介紹第一步：身份驗(yàn)證發(fā)證機(jī)構(gòu)—CA服務(wù)器身份證你是誰(shuí)？我是卓越效勞器身份驗(yàn)證???效勞器卓越效勞器SSL效勞器證書(shū)工作原理介紹第二步：創(chuàng)造密語(yǔ)規(guī)那么密語(yǔ)規(guī)那么發(fā)明規(guī)則A1、2、35、8、9原文密語(yǔ)SSL效勞器證書(shū)工作原理介紹第三步：密語(yǔ)規(guī)那么共享規(guī)則A信息保險(xiǎn)箱翻開(kāi)保險(xiǎn)箱規(guī)則A獲得規(guī)那么SSL效勞器證書(shū)工作原理介紹第四步：進(jìn)行平安通信規(guī)則A規(guī)則A1、2、3原文1、2、3原文5、8、9無(wú)意義文字SSL當(dāng)初并不是為支持電子商務(wù)而設(shè)計(jì)的，所以在電子商務(wù)系統(tǒng)的應(yīng)用中還存在很多弊端:SSL是一個(gè)面向連接的協(xié)議，在涉及多方的電子交易中，只能提供交易中客戶(hù)與效勞器間的雙方認(rèn)證，而電子商務(wù)往往是客戶(hù)、網(wǎng)站、銀行三家協(xié)作完成,SSL協(xié)議并不能協(xié)調(diào)各方間的平安傳輸和信任關(guān)系；購(gòu)貨時(shí)客戶(hù)要輸入通信地址，這樣將可能使得客戶(hù)收到大量垃圾信件。SSL協(xié)議運(yùn)行的基點(diǎn)是商家對(duì)客戶(hù)信息保密的承諾。但在上述流程中SSL協(xié)議有利于商家而不利于客戶(hù)?？蛻?hù)的信息首先傳到商家，商家閱讀后再傳到銀行，這樣，客戶(hù)資料的平安性便受到威脅。隨著電子商務(wù)參與方的迅速增加，認(rèn)證問(wèn)題越來(lái)越突出，SSL協(xié)議的缺點(diǎn)完全暴露出來(lái)。SSL協(xié)議逐漸被新的SET協(xié)議所取代。目前我國(guó)開(kāi)發(fā)的電子支付系統(tǒng)，無(wú)論是中國(guó)銀行的長(zhǎng)城卡電子支付系統(tǒng)，還是上海長(zhǎng)途電信局的網(wǎng)上支付系統(tǒng)，均沒(méi)有采用SSL協(xié)議，主要原因就是無(wú)法保證客戶(hù)資金的平安性。6.1.4SSL協(xié)議的分層結(jié)構(gòu)SSL的設(shè)計(jì)概念是希望使用TCP來(lái)提供一個(gè)可靠的端對(duì)端的平安性效勞。SSL并不是單一個(gè)協(xié)議，而是由二層協(xié)議來(lái)組成SSL協(xié)議具有兩層結(jié)構(gòu):其底層是SSL記錄協(xié)議層〔SSLRecordProtocolLayer〕，簡(jiǎn)稱(chēng)記錄層。其高層是SSL握手協(xié)議層〔SSLHandshakeProtocolLayer〕，簡(jiǎn)稱(chēng)握手層.應(yīng)用層協(xié)議（HTTP、Telnet、FTP、SMTP等）SSL握手協(xié)議（HandshakeProtocol）SSL記錄協(xié)議（RecordProtocol）TCP協(xié)議IP協(xié)議SSL協(xié)議圖6.2SSL協(xié)議的分層結(jié)構(gòu)SSL協(xié)議定義了兩個(gè)通信主體：客戶(hù)〔client〕和效勞器〔server〕。其中，客戶(hù)是協(xié)議的發(fā)起者。在客戶(hù)/效勞器結(jié)構(gòu)中，應(yīng)用層從請(qǐng)求效勞和提供效勞的角度定義客戶(hù)和效勞器，而SSL協(xié)議那么從建立加密參數(shù)的過(guò)程中所扮演的角色來(lái)定義客戶(hù)和效勞器。SSL握手協(xié)議包含四個(gè)階段:第一個(gè)階段建立平安能力;第二個(gè)階段效勞器鑒別和密鑰交換;第三個(gè)階段客戶(hù)鑒別(可選的)和密鑰交換;第四個(gè)階段完成握手協(xié)議。SSL的兩個(gè)重要概念SSL連接〔connection)一個(gè)連接是一個(gè)提供一種適宜類(lèi)型效勞的傳輸〔OSI分層的定義〕。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ù)與效勞器之間的一個(gè)關(guān)聯(lián)。會(huì)話(huà)由HandshakeProtocol創(chuàng)立。會(huì)話(huà)定義了一組可供多個(gè)連接共享的密碼平安參數(shù)。會(huì)話(huà)用以防止為每一個(gè)連接提供新的平安參數(shù)所需昂貴的協(xié)商代價(jià)。會(huì)話(huà)連接1連接1連接2連接2…………連接n連接n圖6.3SSL的會(huì)話(huà)與連接在任意一對(duì)通信主體之間，可以有多個(gè)平安連接。會(huì)話(huà)狀態(tài)參數(shù)Sessionidentifier:效勞器選擇的一個(gè)任意字節(jié)序列，用以標(biāo)識(shí)一個(gè)活動(dòng)的或可激活的會(huì)話(huà)狀態(tài)。PeerCertificate:標(biāo)識(shí)效勞器的證書(shū)。可為空。Compressionmethod:加密前進(jìn)行數(shù)據(jù)壓縮的算法。Cipherspec:指明數(shù)據(jù)體加密的算法〔無(wú)，或DES等〕以及散列算法〔如MD5或SHA-1〕用以計(jì)算MAC。還包括其它參數(shù)，如散列長(zhǎng)度。Mastersecret:48位秘密，在client與server之間共享。Isresumable:一個(gè)標(biāo)志，指明該會(huì)話(huà)是否能用于產(chǎn)生一個(gè)新連接。連接狀態(tài)Serverandclientrandom:server和client為每一個(gè)連接所選擇的字節(jié)序號(hào)。ServerwriteMACsecret:一個(gè)密鑰，用來(lái)對(duì)server送出的數(shù)據(jù)進(jìn)行MAC操作。ClientwriteMACsecret:一個(gè)密鑰，用來(lái)對(duì)client送出的數(shù)據(jù)進(jìn)行MAC操作。

Serverwritekey:用于server進(jìn)行數(shù)據(jù)加密，client進(jìn)行數(shù)據(jù)解密的對(duì)稱(chēng)保密密鑰；連接狀態(tài)Clientwritekey:用于client進(jìn)行數(shù)據(jù)加密，server進(jìn)行數(shù)據(jù)解密的對(duì)稱(chēng)保密密鑰；Initializationvectors:當(dāng)數(shù)據(jù)加密采用CBC方式時(shí)，每一個(gè)密鑰保持一個(gè)IV。該字段首先由SSLHandshakeProtocol產(chǎn)生，以后保存每次最后的密文數(shù)據(jù)塊作為IV。Sequencenumber:每一方為每一個(gè)連接的數(shù)據(jù)發(fā)送與接收維護(hù)單獨(dú)的順序號(hào)。當(dāng)一方發(fā)送或接收一個(gè)改變的cipherspecmessage時(shí)，序號(hào)置為0,最大264-1。6.2SSL握手協(xié)議(Handshakeprotocol)主要用來(lái)讓客戶(hù)端及效勞器確認(rèn)彼此的身分。為了保護(hù)SSL記錄封包中傳送的數(shù)據(jù)，Handshake協(xié)議還能協(xié)助雙方選擇連接時(shí)所會(huì)使用的加密算法、MAC算法、及相關(guān)密鑰。在傳送應(yīng)用程序的數(shù)據(jù)前，必須使用Handshake協(xié)議來(lái)完成上述事項(xiàng)。Handshake由一些客戶(hù)與效勞器交換的消息所構(gòu)成，每一個(gè)消息都含有以下三個(gè)字段：類(lèi)型(Type)，1字節(jié)：表示消息的類(lèi)型，總共有十種。在表二中列出了這些已經(jīng)定義的消息種類(lèi)。長(zhǎng)度(Length)，3字節(jié)：消息的位組長(zhǎng)度。內(nèi)容(Content)，≧1個(gè)字節(jié)：與此消息有關(guān)的參數(shù)，表6.1列出所有可能的參數(shù)。SSL握手協(xié)議使用的消息第一階段：建立起平安協(xié)商客戶(hù)發(fā)送一個(gè)client_hello消息，包括以下參數(shù)：版本、隨機(jī)數(shù)(32位時(shí)間戳+28字節(jié)隨機(jī)序列)、會(huì)話(huà)ID、客戶(hù)支持的密碼算法列表(CipherSuite)、客戶(hù)支持的壓縮方法列表,然后，客戶(hù)等待效勞器的server_hello消息效勞器發(fā)送server_hello消息，參數(shù)：客戶(hù)建議的低版本以及效勞器支持的最高版本、效勞器產(chǎn)生的隨機(jī)數(shù)、會(huì)話(huà)ID、效勞器從客戶(hù)建議的密碼算法中挑出一套、效勞器從客戶(hù)建議的壓縮方法中挑出一個(gè).CipherSuite密碼套件

第一個(gè)元素指定了密鑰交換的方法，SSL支持以下一些方法：RSA，要求效勞器提供一個(gè)RSA證書(shū)DH(Diffie-Hellman)，要求效勞器的證書(shū)中包含了由CA簽名的DH公開(kāi)參數(shù)?？蛻?hù)或者在證書(shū)中提供DH公開(kāi)參數(shù)，或者在密鑰交換消息中提供此參數(shù)第二階段：效勞器鑒別和密鑰交換效勞器發(fā)送自己的證書(shū)，消息包含一個(gè)X.509證書(shū)，或者一條證書(shū)鏈效勞器發(fā)送server_key_exchange消息可選的，有些情況下可以不需要。只有當(dāng)效勞器的證書(shū)沒(méi)有包含必需的數(shù)據(jù)的時(shí)候才發(fā)送此消息消息包含簽名，被簽名的內(nèi)容包括兩個(gè)隨機(jī)數(shù)以及效勞器參數(shù)效勞器發(fā)送certificate_request消息非匿名server可以向客戶(hù)請(qǐng)求一個(gè)證書(shū)包含證書(shū)類(lèi)型和CAs效勞器發(fā)送server_hello_done,然后等待應(yīng)答第三階段：客戶(hù)鑒別和密鑰交換客戶(hù)收到server_done消息后，它根據(jù)需要檢查效勞器提供的證書(shū)，并判斷server_hello的參數(shù)是否可以接受，如果都沒(méi)有問(wèn)題的話(huà)，發(fā)送一個(gè)或多個(gè)消息給效勞器如果效勞器請(qǐng)求證書(shū)的話(huà)，那么客戶(hù)首先發(fā)送一個(gè)certificate消息，假設(shè)客戶(hù)沒(méi)有證書(shū)，那么發(fā)送一個(gè)no_certificate警告?然后客戶(hù)發(fā)送client_key_exchange消息最后，客戶(hù)發(fā)送一個(gè)certificate_verify消息，其中包含一個(gè)簽名，對(duì)從第一條消息以來(lái)的所有握手消息的MAC值()進(jìn)行簽名第四階段：結(jié)束第四階段建立起一個(gè)平安的連接客戶(hù)發(fā)送一個(gè)change_cipher_spec消息，并且把協(xié)商得到的CipherSuite拷貝到當(dāng)前連接的狀態(tài)之中然后，客戶(hù)用新的算法、密鑰參數(shù)發(fā)送一個(gè)finished消息，這條消息可以檢查密鑰交換和鑒別過(guò)程是否已經(jīng)成功。其中包括一個(gè)校驗(yàn)值，對(duì)所有以來(lái)的消息進(jìn)行校驗(yàn)。效勞器同樣發(fā)送change_cipher_spec消息和finished消息。握手過(guò)程完成，客戶(hù)和效勞器可以交換應(yīng)用層數(shù)據(jù)。SSL握手協(xié)議的流程交換Hello消息，對(duì)于算法、交換隨機(jī)值等協(xié)商一致交換必要的密碼參數(shù)，以便雙方得到統(tǒng)一的premastersecret交換證書(shū)和相應(yīng)的密碼信息，以便進(jìn)行身份認(rèn)證產(chǎn)生mastersecret把平安參數(shù)提供給SSL記錄層檢驗(yàn)雙方是否已經(jīng)獲得同樣的平安參數(shù)6.3SSL記錄協(xié)議(SSLRecordProtocol)SSL記錄協(xié)議為每一個(gè)SSL連接提供以下兩種效勞：機(jī)密性(Confidentiality)：SSL記錄協(xié)議會(huì)協(xié)助雙方產(chǎn)生一把共有的密鑰，利用這把密鑰來(lái)對(duì)SSL所傳送的數(shù)據(jù)做傳統(tǒng)式加密。消息完整性(MessageIntegrity)：SSL記錄協(xié)議會(huì)協(xié)助雙方產(chǎn)生另一把共有的密鑰，利用這把密鑰來(lái)計(jì)算出消息認(rèn)證碼。SSL數(shù)據(jù)單元的形成過(guò)程用戶(hù)數(shù)據(jù)單元分段壓縮附加MAC加密附加SSL報(bào)頭SSL記錄協(xié)議操作流程第一個(gè)步驟是分片(fragmentation)。每個(gè)上層應(yīng)用數(shù)據(jù)被分成214字節(jié)或更小的數(shù)據(jù)塊。記錄中包含類(lèi)型、版本號(hào)、長(zhǎng)度和數(shù)據(jù)字段.選擇是否執(zhí)行壓縮的步驟(compression)。壓縮的過(guò)程中，必須是無(wú)損失壓縮(lossless)，也就是說(shuō)解壓縮后能夠得到原本完整的消息。經(jīng)過(guò)壓縮后的內(nèi)容長(zhǎng)度不能超過(guò)原有長(zhǎng)度1024字節(jié)以上,在SSLv3〔以及TLS的現(xiàn)有版本〕，并沒(méi)有指定壓縮算法，所以預(yù)設(shè)的算法是null。計(jì)算壓縮數(shù)據(jù)的消息認(rèn)證碼(messageauthenticationcode)。為了到達(dá)這個(gè)目的，必須使用一把雙方共有的密鑰。SSLRecordFormat6.4SSL協(xié)議采用的加密和認(rèn)證算法6.4.1加密算法塊加密流加密加密算法密鑰長(zhǎng)度加密算法密鑰長(zhǎng)度IDEARC2-40DES-40DES3DESFortezza12840405616880RC440RC4-128401286.4.2認(rèn)證算法 認(rèn)證算法采用X.509電子證書(shū)標(biāo)準(zhǔn)，通過(guò)使用RSA算法進(jìn)行數(shù)字簽名來(lái)實(shí)現(xiàn)的。⑴效勞器的認(rèn)證：效勞器方的寫(xiě)密鑰和客戶(hù)方的讀密鑰、客戶(hù)方的寫(xiě)密鑰和效勞器方的讀密鑰分別是一對(duì)私有、公有密鑰。⑵客戶(hù)的認(rèn)證：6.4.3會(huì)話(huà)層的密鑰分配協(xié)議⑴SKEIP〔SimpleKeyExchangeforInternetProtocol〕。由公鑰證書(shū)來(lái)實(shí)現(xiàn)兩個(gè)通信實(shí)體間的長(zhǎng)期單鑰的交換。證書(shū)通過(guò)用戶(hù)數(shù)據(jù)協(xié)議UDP得到⑵Photuris。SKEIP有其不利的一面，假設(shè)某人能得到長(zhǎng)期SKEIP密鑰，他就可以解出所有以前用此密鑰加密的信息，而Photuris只用長(zhǎng)期密鑰認(rèn)證會(huì)話(huà)密鑰，那么無(wú)此問(wèn)題。但Photuris效率沒(méi)有SKEIP高。⑶ISAKMP(Internet平安協(xié)會(huì)的密鑰管理協(xié)議)。和前兩者不同，ISAKMP只提供密鑰管理的一般框架，而不限定密鑰管理協(xié)議，也不限定密鑰算法或協(xié)議，因此在使用和策略上更為靈活。6.5SSL協(xié)議平安性分析6.5.1平安機(jī)制分析⑴鑒別機(jī)制。 公開(kāi)密鑰技術(shù)和數(shù)字證書(shū)可以實(shí)現(xiàn)客戶(hù)端和效勞器端的身份鑒別。ClientHello和ServerHello發(fā)過(guò)去自己的證書(shū)(里面包含了身份和自己的公鑰)。⑵加密機(jī)制。 混合密碼體制的使用提供了會(huì)話(huà)和數(shù)據(jù)傳輸?shù)募用苄员Ｗo(hù)。雙方使用非對(duì)稱(chēng)密碼體制協(xié)商出本次將要使用的會(huì)話(huà)密鑰，并選擇一種對(duì)稱(chēng)加密算法。⑶完整性機(jī)制。 定義了共享的、可以用來(lái)形成報(bào)文鑒別碼MAC的密鑰。數(shù)據(jù)進(jìn)行分片壓縮后，使用單向散列函數(shù)產(chǎn)生一個(gè)MAC，加密后置于數(shù)據(jù)包的后部，并且再一次和數(shù)據(jù)一起被加密,然后加上SSL首部進(jìn)行網(wǎng)絡(luò)傳輸。 這樣，如果數(shù)據(jù)被修改，其散列值就無(wú)法和原來(lái)的MAC相匹配，從而保證了數(shù)據(jù)的完整性。⑷抗重放攻擊。 SSL使用序列號(hào)來(lái)保護(hù)通信方免受報(bào)文重放攻擊。這個(gè)序列號(hào)被加密后作為數(shù)據(jù)包的負(fù)載。 在整個(gè)SSL握手中，都有一個(gè)唯一的隨機(jī)數(shù)來(lái)標(biāo)記這個(gè)SSL握手，這樣重放便無(wú)機(jī)可乘。6.5.2脆弱性分析1.客戶(hù)端假冒因?yàn)镾SL協(xié)議設(shè)計(jì)初衷是對(duì)Web站點(diǎn)及網(wǎng)上交易進(jìn)行平安性保護(hù)，使消費(fèi)者明白正在和誰(shuí)進(jìn)行交易要比使商家知道誰(shuí)正在付費(fèi)更為重要，為了不致于由于平安協(xié)議的使用而導(dǎo)致網(wǎng)絡(luò)性能大幅下降，SSL協(xié)議并不是默認(rèn)地要求進(jìn)行客戶(hù)鑒別，這樣做雖然有悖于平安策略，但卻促進(jìn)了SSL的廣泛應(yīng)用。針對(duì)這個(gè)問(wèn)題，可在必要的時(shí)候配置SSL協(xié)議，使其選擇對(duì)客戶(hù)端進(jìn)行認(rèn)證鑒別。2.SSL協(xié)議無(wú)法提供基于UDP應(yīng)用的平安保護(hù)SSL協(xié)議需要在握手之前建立TCP連接，因此不能對(duì)UDP應(yīng)用進(jìn)行保護(hù)。如果要兼顧UDP協(xié)議層之上的平安保護(hù)，可以采用IP層的平安解決方案。3.SSL協(xié)議不能對(duì)抗通信流量分析由于SSL只對(duì)應(yīng)用數(shù)據(jù)進(jìn)行保護(hù)，數(shù)據(jù)包的IP頭和TCP頭仍然暴露在外，通過(guò)檢查沒(méi)有加密的IP源和目的地址以及TCP端口號(hào)或者檢查通信數(shù)據(jù)量，一個(gè)通信分析者依然可以揭示哪一方在使用什么效勞，有時(shí)甚至揭露商業(yè)或私人關(guān)系的秘密。4.進(jìn)程中主密鑰泄漏除非SSL的工程實(shí)現(xiàn)大局部駐留在硬件中，否那么主密鑰將會(huì)存留在主機(jī)的主存儲(chǔ)器中，這就意味著任何可以讀取SSL進(jìn)程存儲(chǔ)空間的攻擊者都能讀取主密鑰，因此，不可能面對(duì)掌握機(jī)器管理特權(quán)的攻擊者而保護(hù)SSL連接，這個(gè)問(wèn)題要依靠用戶(hù)管理策略來(lái)解決。5.磁盤(pán)上的臨時(shí)文件可能遭受攻擊對(duì)于使用虛擬內(nèi)存的操作系統(tǒng)，不可防止地有些敏感數(shù)據(jù)甚至主密鑰都交換到存盤(pán)上，可采取內(nèi)存加鎖和及時(shí)刪除磁盤(pán)臨時(shí)文件等措施來(lái)降低風(fēng)險(xiǎn)。6.對(duì)證書(shū)的攻擊和竊取類(lèi)似Verisign之類(lèi)的公共CA機(jī)構(gòu)并不總是可靠的，系統(tǒng)管理員經(jīng)常犯的錯(cuò)誤是過(guò)于信任這樣的公共CA機(jī)構(gòu)。因?yàn)閷?duì)于用戶(hù)的證書(shū)，公共CA機(jī)構(gòu)可能不像對(duì)網(wǎng)站數(shù)字證書(shū)那樣重視和關(guān)心其準(zhǔn)確性。

3.平安盲點(diǎn)系統(tǒng)管理員不能使用現(xiàn)有的平安漏洞掃描或網(wǎng)絡(luò)入侵檢測(cè)系統(tǒng)來(lái)審查或監(jiān)控網(wǎng)絡(luò)上的SSL交易。加密技術(shù)使得通過(guò)網(wǎng)絡(luò)傳輸?shù)男畔o(wú)法讓IDS識(shí)別.使得最重要的效勞器反而成為受到最少防護(hù)的效勞器。對(duì)此，惡意代碼檢測(cè)、增強(qiáng)的日志功能等基于主機(jī)的平安策略會(huì)成為最后防線。SSL仍然不失為一套全面完善的平安策略中有效的組成元素。然而，與網(wǎng)絡(luò)平安的其它工具軟件一樣，僅使用單一的防護(hù)軟件都是遠(yuǎn)遠(yuǎn)不夠的。對(duì)SSL的過(guò)高評(píng)價(jià)有可能帶來(lái)高的平安風(fēng)險(xiǎn)，它僅僅是網(wǎng)絡(luò)平安工具的一種，必須和其它網(wǎng)絡(luò)平安工具緊密結(jié)合，方能構(gòu)造出全面、完善、平安可靠的網(wǎng)絡(luò)。Web平安威脅Web的全稱(chēng)是WorldWideWeb。Web面臨的主要平安威脅如下：Web效勞器上的Web網(wǎng)頁(yè)很容易收到攻擊Web的下層軟件結(jié)構(gòu)復(fù)雜，存在大量的安全漏洞當(dāng)Web效勞器遭到破壞時(shí)，本地站點(diǎn)上的數(shù)據(jù)和系統(tǒng)也將面臨威脅?！餐{的蔓延〕瀏覽器:如IE和Netscape等Web效勞器:IIS、Domino

Go

WebServerNetscape

Enterprise

ServerAppache在瀏覽器端安裝支持SSL的客戶(hù)端證書(shū)〔可選〕，然后把URL中的“://〞更換為“s://〞。CGI程序的平安性問(wèn)題CGI是CommonGatewayInterface〔通用網(wǎng)關(guān)接口〕的簡(jiǎn)寫(xiě)，它是一個(gè)Web效勞器主機(jī)提供信息效勞的標(biāo)準(zhǔn)接口，通過(guò)提供這樣一個(gè)標(biāo)準(zhǔn)接口，Web效勞器能夠執(zhí)行應(yīng)用程序并將它們的輸出，如文字、圖形、聲音等傳遞給一個(gè)Web瀏覽器CGI程序是WWW平安漏洞的主要來(lái)源編寫(xiě)平安的CGI腳本4.2WWW的平安Web效勞器端平安性效勞器發(fā)布信息，提供效勞靜態(tài)信息，各種HTML頁(yè)面動(dòng)態(tài)信息，利用腳本或者各種擴(kuò)展引擎響應(yīng)客戶(hù)的請(qǐng)求平安性目錄平安性只有指定范圍的文件才可以被訪問(wèn)例如，禁止URL中出現(xiàn)“..〞Cgi文件的平安性，此目錄禁止通過(guò)Web讀寫(xiě)檢查每一個(gè)cgi文件，不要保存有漏洞的cgi文件，特別是系統(tǒng)預(yù)裝的一些cgi例如文件，這些文件往往為了說(shuō)明功能，而忽略了平安性的考慮要求鑒別：由于協(xié)商的原因，要注意平安性最低的鑒別協(xié)議授權(quán)機(jī)制：保護(hù)好口令的平安存儲(chǔ)，以及客戶(hù)信息的保存日志：翻開(kāi)系統(tǒng)中對(duì)于Web效勞的日志功能，以及Web效勞的日志記錄效勞器端的平安防護(hù)有些應(yīng)用使用SSL/TLS，為WebService申請(qǐng)一個(gè)證書(shū)WebServer往往是網(wǎng)絡(luò)攻擊的入口點(diǎn)為了提供WebService，必須要開(kāi)放端口和一些目錄，還要接受各種正常的連接請(qǐng)求防火墻對(duì)WebServer的保護(hù)是有限的為了平安，請(qǐng):及時(shí)打上WebServer軟件廠商提供的補(bǔ)丁程序特別是一些主流的效勞軟件，比方MS的IIS控制目錄和文件的權(quán)限Web應(yīng)用開(kāi)發(fā)人員注意在效勞端的運(yùn)行代碼中，對(duì)于來(lái)自客戶(hù)端的輸入一定要進(jìn)行驗(yàn)證防止緩沖區(qū)溢出平安Web效勞器平安Web效勞器在提供常規(guī)的Web效勞的同時(shí)，還具有以下特點(diǎn)：WEB頁(yè)面加密存儲(chǔ)方法，確保存儲(chǔ)在WEB效勞器上的頁(yè)面文件的平安性；WEB頁(yè)面的原始性鑒別技術(shù)；分密級(jí)訪問(wèn)控制，確保不被非法訪問(wèn)；嚴(yán)格的傳輸加密技術(shù)，確保信息不被監(jiān)聽(tīng)；數(shù)字水印日志，確保日志文件不可更改，為計(jì)算機(jī)取證提供支持；Web客戶(hù)端的平安性客戶(hù)端平安性涉及到Cookie的設(shè)置，保護(hù)用戶(hù)的隱私PKI設(shè)置，確定哪些是可信任的CA對(duì)可執(zhí)行代碼的限制，包括JavaApplet，ActiveXcontrol如果你的機(jī)器是多個(gè)人合用的，那么Web頁(yè)面的緩存區(qū)域，將會(huì)留下用戶(hù)最近訪問(wèn)過(guò)的頁(yè)面歷史記錄口令自動(dòng)保存和提示……4.2.6Plug-in的平安性Plug-