【正文】 進(jìn)行昂貴的新安全參數(shù)的協(xié)商。同樣，當(dāng) SSL協(xié)議從傳輸層接收到數(shù)據(jù)后需要對其進(jìn)行解密等操作后才能交給上層的應(yīng)用層。 2023/2/27 星期六 25Ch7網(wǎng)絡(luò)安全協(xié)議上層報文分片 1 分片 2 分片 n壓縮 (可選）加密增加 MAC增加 SSL記錄首部圖 SSL記錄協(xié)議的發(fā)送方執(zhí)行的操作步驟2023/2/27 星期六 26Ch7網(wǎng)絡(luò)安全協(xié)議? SSL記錄協(xié)議中 發(fā)送方 執(zhí)行的操作步驟：① 從上層接受傳輸?shù)膽?yīng)用報文；② 分片： 將數(shù)據(jù)分片成可管理的塊，每個上層報文被分成 16KB或更小的數(shù)據(jù)塊；③ 進(jìn)行數(shù)據(jù)壓縮 (可選 )：壓縮是可選的，壓縮的前提是不能丟失信息，并且增加的內(nèi)容長度不能超過 1024字節(jié)，缺省的壓縮算法為空；④ 應(yīng)用 MAC： 加入 信息認(rèn)證碼（ MAC）， 這一步需要用到共享的密鑰；⑤ 加密：利用 IDEA、 DES、 3DES或其他加密算法對壓縮報文和 MAC碼進(jìn)行數(shù)據(jù)加密；⑥ 增加 SSL首部：增加由內(nèi)容類型、主要版本、次要版本和壓縮長度組成的首部。 2023/2/27 星期六 27Ch7網(wǎng)絡(luò)安全協(xié)議? SSL記錄協(xié)議中 接收方接收數(shù)據(jù)的 工作過程① 從低層接受報文；② 解密； ③ 用事先商定的 MAC碼校驗數(shù)據(jù)；④ 如果是壓縮的數(shù)據(jù)，則解壓縮；⑤ 重裝配數(shù)據(jù)；⑥ 傳輸信息到上層。任何時候客戶都能請求修改密碼參數(shù)，比如握手密鑰交換。此后，新的雙方約定的密鑰就將一直使用到下次提出修改密鑰規(guī)約請求為止。和其他使用 SSL的情況一樣，告警報文按照當(dāng)前狀態(tài)說明被壓縮和加密。第一個字節(jié)的值用來表明警告的的級別，第二個字節(jié)表示特定告警的代碼。 警示消息有兩種 :一種是 Fatal錯誤 ,如傳遞數(shù)據(jù)過程中，發(fā)現(xiàn)錯誤的 MAC， 雙方就需要立即中斷會話，同時消除自己緩沖區(qū)相應(yīng)的會話記錄；第二種是 Warning消息，這種情況，通信雙方通常都只是記錄日志，而對通信過程不造成任何影響。? 會話狀態(tài) ：① 會話標(biāo)識符② 對方的證書③ 壓縮方法④ 密文規(guī)約⑤ 主密鑰⑥ 可重新開始標(biāo)志? 連接狀態(tài) ：① 服務(wù)器和客戶隨機(jī)數(shù)② 服務(wù)器寫 MAC密鑰③ 客戶寫 MAC密鑰④ 服務(wù)器寫密鑰⑤ 客戶寫密鑰⑥ 初始化向量⑦ 序號2023/2/27 星期六 31Ch7網(wǎng)絡(luò)安全協(xié)議 SSL握手 協(xié)議 用于 鑒別 初始化和 傳輸密 鑰 ，它使得服 務(wù) 器和客 戶 能相互 鑒別對方的身份，并保 護(hù) 在 SSL記錄 中 發(fā) 送的數(shù)據(jù)。 2023/2/27 星期六 32Ch7網(wǎng)絡(luò)安全協(xié)議圖 SSL握手過程 SSL客戶端 SSL服務(wù)器端發(fā)送 ” hello” 消息傳送數(shù)據(jù)回復(fù) ” hello” 消息 ,發(fā)出服務(wù)器證書 ,服務(wù)器密鑰交換信息 ,證書請求 ,服務(wù)器 HELLO DONE發(fā)送證書 ,客戶密鑰交換信息 ,證書驗證信息 ,結(jié)束發(fā)修改密文規(guī)約信息結(jié)束發(fā)修改密文規(guī)約信息傳送數(shù)據(jù)214352023/2/27 星期六 33Ch7網(wǎng)絡(luò)安全協(xié)議SSL握手的詳細(xì)過程? 第一步：客戶發(fā)出一個帶有客戶 HELLO信息的連接請求。② 時間信息，以標(biāo)準(zhǔn)的 UNIX32位格式標(biāo)識的現(xiàn)時和日期。包括認(rèn)證碼、密鑰交換方法、加密和 MAC算法）。⑥ 隨機(jī)數(shù)。 在服務(wù)器 HELLO信息之后，服務(wù)器發(fā)出如下信息： ① 服務(wù)器證書，如果服務(wù)器需要被鑒別的話。 ③ 證書請求，如果客戶要求被鑒別的話。2023/2/27 星期六 35Ch7網(wǎng)絡(luò)安全協(xié)議SSL握手的詳細(xì)過程? 第三步：客戶發(fā)送下列信息：① 如果服務(wù)器發(fā)出了一個證書請求，那么客戶方必須發(fā)送一個證書或非證書信息。③ 如果客戶方已經(jīng)發(fā)送了一個證書，那么客戶方就需驗證服務(wù)器方的證書并且發(fā)出一個證書驗證信息指明結(jié)果。客戶方還發(fā)送一個修改密文規(guī)約信息來產(chǎn)生共享的常規(guī)密鑰。2023/2/27 星期六 36Ch7網(wǎng)絡(luò)安全協(xié)議SSL握手的詳細(xì)過程? 第四步：服務(wù)器發(fā)出一個結(jié)束信息指出協(xié)商協(xié)商階段完成。? 第五步：會 話 雙方分 別產(chǎn) 生一個加密密 鑰 ，然后他 們 再根據(jù) 這 些密 鑰導(dǎo) 出會 話 主密 鑰 。所有從 應(yīng) 用 層 的來的數(shù)據(jù) 傳輸 作 為 特定信息 傳輸給對 方。 它建立在Netscape所提出的 。 2023/2/27 星期六 38Ch7網(wǎng)絡(luò)安全協(xié)議 SSL協(xié)議應(yīng)用 ? 一個使用 WEB客戶機(jī)和服務(wù)器的范例 WEB客戶機(jī)通過連接到一個支持 SSL的服務(wù)器，啟動一次 SSL會話。當(dāng)客戶機(jī)連接到這個端口上時，它將啟動一次建立 SSL會話的握手。 SSL創(chuàng)建一個會話，在此期間，握手必須只發(fā)生過一次。? 步驟 2：服務(wù)器通過發(fā)送它的數(shù)字證書證明其身份。 通過檢查有效日期并確認(rèn)證書包含有可信任 CA的數(shù)字簽名，來驗證證書。但是，因為缺乏公鑰體系結(jié)構(gòu)，當(dāng)今的大多數(shù)服務(wù)器不進(jìn)行客戶端認(rèn)證。通常由客戶機(jī)提供它支持的所有算法列表，然后由服務(wù)器選擇最強(qiáng)健的加密算法。 （從客戶機(jī)的密鑰可用時則使用客戶機(jī)密鑰；否則以明文方式發(fā)送數(shù)據(jù)）響應(yīng)。 2023/2/27 星期六 41Ch7網(wǎng)絡(luò)安全協(xié)議SSL協(xié)議的優(yōu)點? 機(jī)密性 即連接是私有的。? 完整性 在信息中嵌入信息鑒別碼（ MAC） 來保證信息的完整性。? 鑒別 在握手階段，客戶鑒別服務(wù)器用不對稱密鑰或公開密鑰。? SSL協(xié)議 主要是使用公開密 鑰 體制和 證書 技 術(shù) 保 護(hù) 信息 傳輸 的機(jī)密性和完整性，它不能保 證 信息的不可抵 賴 性，主要適用于點 對 點之 間 的信息 傳輸 ，常用 Web Server方式。2023/2/27 星期六 43Ch7網(wǎng)絡(luò)安全協(xié)議 IPSec協(xié)議 由于協(xié)議 IPv4最初設(shè)計時沒有過多地考慮安全性，缺乏對通信雙方真實身份的驗證能力，缺乏對網(wǎng)上傳輸?shù)臄?shù)據(jù)的完整性和機(jī)密性保護(hù)，并且由于 IP地址可軟件配置等靈活性以及基于源 IP地址的認(rèn)證機(jī)制，使 IP層存在著網(wǎng)絡(luò)業(yè)務(wù)流易被監(jiān)聽和捕獲、 IP地址欺騙、信息泄漏和數(shù)據(jù)項被篡改等多種攻擊，而 IP是很難抵抗這些攻擊的。 2023/2/27 星期六 44Ch7網(wǎng)絡(luò)安全協(xié)議IPSec協(xié)議組? 網(wǎng)絡(luò)認(rèn)證協(xié)議 Authentication Header（ AH）? 封裝安全載荷協(xié)議 Encapsulating Security Payload（ ESP）? 密鑰管理協(xié)議 Inter Key Exchange （ IKE）? 網(wǎng)絡(luò)認(rèn)證及加密算法 2023/2/27 星期六 45Ch7網(wǎng)絡(luò)安全協(xié)議 IPSec安全體系結(jié)構(gòu)圖 IPSec安全體系結(jié)構(gòu) IPSec體系結(jié)構(gòu)ESP協(xié)議 AH協(xié)議加密算法DOI密鑰管理認(rèn)證算法2023/2/27 星期六 46Ch7網(wǎng)絡(luò)安全協(xié)議? ESP協(xié)議規(guī)定了為通信提供機(jī)密性和完整性保護(hù)的具體方案，包括 ESP載荷的格式、語義、取值以及對進(jìn)入分組和外出分組的處理過程等。? AH協(xié)議定義了認(rèn)證的應(yīng)用方法，提供數(shù)據(jù)源認(rèn)證和完整性保證。 2023/2/27 星期六 47Ch7網(wǎng)絡(luò)安全協(xié)議安全關(guān)聯(lián)（ Security Association， SA） 為了正確封裝及提取 IPSec數(shù)據(jù)包，有必要采取一套專門的方案，將安全服務(wù) /密鑰與要保護(hù)的通信數(shù)據(jù)聯(lián)系到一起；同時要將遠(yuǎn)程通信實體與要交換密鑰的 IPSec數(shù)據(jù)傳輸聯(lián)系到一起。這樣的構(gòu)建方案稱為安全關(guān)聯(lián)（ Security Association， SA）。也就是說，在一次通信中， IPSec 需要建立兩個 SA， 一個用于入站通信，另一個用于出站通信。 2023/2/27 星期六 49Ch7網(wǎng)絡(luò)安全協(xié)議 AH（ Authentication Header） 協(xié)議 AH協(xié)議規(guī)定了 AH頭在 AH實現(xiàn)中應(yīng)插入 IP頭的位置、 AH頭的語法格式、各字段的語義及取值方式，以及實施 AH時進(jìn)入和外出分組的處理過程。