【文章內(nèi)容簡介】 是記錄日志，而對通信過程不造成任何影響。 2023/2/27 星期六 30Ch7網(wǎng)絡安全協(xié)議 SSL握手協(xié)議 一個 SSL會話工作在不同的狀態(tài)，即會話狀態(tài)和連接狀態(tài)。? 會話狀態(tài) ：① 會話標識符② 對方的證書③ 壓縮方法④ 密文規(guī)約⑤ 主密鑰⑥ 可重新開始標志? 連接狀態(tài) ：① 服務器和客戶隨機數(shù)② 服務器寫 MAC密鑰③ 客戶寫 MAC密鑰④ 服務器寫密鑰⑤ 客戶寫密鑰⑥ 初始化向量⑦ 序號2023/2/27 星期六 31Ch7網(wǎng)絡安全協(xié)議 SSL握手 協(xié)議 用于 鑒別 初始化和 傳輸密 鑰 ，它使得服 務 器和客 戶 能相互 鑒別對方的身份，并保 護 在 SSL記錄 中 發(fā) 送的數(shù)據(jù)。因此在 傳輸 任何 應 用數(shù)據(jù)前，都必 須使用握手 協(xié)議 。 2023/2/27 星期六 32Ch7網(wǎng)絡安全協(xié)議圖 SSL握手過程 SSL客戶端 SSL服務器端發(fā)送 ” hello” 消息傳送數(shù)據(jù)回復 ” hello” 消息 ,發(fā)出服務器證書 ,服務器密鑰交換信息 ,證書請求 ,服務器 HELLO DONE發(fā)送證書 ,客戶密鑰交換信息 ,證書驗證信息 ,結(jié)束發(fā)修改密文規(guī)約信息結(jié)束發(fā)修改密文規(guī)約信息傳送數(shù)據(jù)214352023/2/27 星期六 33Ch7網(wǎng)絡安全協(xié)議SSL握手的詳細過程? 第一步：客戶發(fā)出一個帶有客戶 HELLO信息的連接請求。這信息包括：① 想要使用的 SSL版本號。② 時間信息，以標準的 UNIX32位格式標識的現(xiàn)時和日期。③ 會話標識（可選），如果沒有指定的話，則服務器便重用上一次的會話標識或返回一個錯誤信息④ 密文組（客戶方所支持的各種加密算法選項清單。包括認證碼、密鑰交換方法、加密和 MAC算法）。⑤ 客戶方所支持的壓縮算法。⑥ 隨機數(shù)。2023/2/27 星期六 34Ch7網(wǎng)絡安全協(xié)議SSL握手的詳細過程? 第二步：服務器評估客戶方發(fā)來的 HELLO信息中的各項參數(shù)，并且返回一個服務器方的 HELLO信息，其中含有服務器選來用于 SSL會話的各項參數(shù)（版本號、時間信息、以標準的 UNIX32位格式標識的現(xiàn)時和日期、會話標識、密文組、壓縮方法、隨機數(shù)）。 在服務器 HELLO信息之后，服務器發(fā)出如下信息： ① 服務器證書，如果服務器需要被鑒別的話。 ②服務器密鑰交換信息，如果得不到證書或證書僅僅用作簽名的話。 ③ 證書請求，如果客戶要求被鑒別的話。 最后，服務器發(fā)出一個服務器 HELLO DONE信息，開始等待客戶的回音。2023/2/27 星期六 35Ch7網(wǎng)絡安全協(xié)議SSL握手的詳細過程? 第三步：客戶發(fā)送下列信息：① 如果服務器發(fā)出了一個證書請求，那么客戶方必須發(fā)送一個證書或非證書信息。② 如果服務器發(fā)送了一個服務器密鑰交換信息，那么客戶方就發(fā)送一個基于公鑰算法的由 HELLO信息決定的密鑰交換信息。③ 如果客戶方已經(jīng)發(fā)送了一個證書，那么客戶方就需驗證服務器方的證書并且發(fā)出一個證書驗證信息指明結(jié)果。 然后，客戶方發(fā)出一個結(jié)束信息，指出協(xié)商過程已經(jīng)完成。客戶方還發(fā)送一個修改密文規(guī)約信息來產(chǎn)生共享的常規(guī)密鑰。應該注意這部分工作不是由握手協(xié)議控制，是由修改密文規(guī)約協(xié)議管理的。2023/2/27 星期六 36Ch7網(wǎng)絡安全協(xié)議SSL握手的詳細過程? 第四步：服務器發(fā)出一個結(jié)束信息指出協(xié)商協(xié)商階段完成。然后服務器發(fā)出一個密文修改規(guī)約信息。? 第五步：會 話 雙方分 別產(chǎn) 生一個加密密 鑰 ，然后他 們 再根據(jù) 這 些密 鑰導 出會 話 主密 鑰 。握手協(xié)議 改 變 狀 態(tài) 至 連 接狀 態(tài) 。所有從 應 用 層 的來的數(shù)據(jù) 傳輸 作 為 特定信息 傳輸給對 方。 2023/2/27 星期六 37Ch7網(wǎng)絡安全協(xié)議 TLS協(xié)議 傳輸層安全 TLS(Transport Layer Security)協(xié)議是 IETF正在定義一種新的協(xié)議 。 它建立在Netscape所提出的 。 兩個互相不知其代碼的應用程序可用 TLS來安全地通信。 2023/2/27 星期六 38Ch7網(wǎng)絡安全協(xié)議 SSL協(xié)議應用 ? 一個使用 WEB客戶機和服務器的范例 WEB客戶機通過連接到一個支持 SSL的服務器，啟動一次 SSL會話。支持 SSL的典型 WEB服務器在一個與標準 HTTP請求（默認為端口 80）不同的端口（默認為 443）上接受 SSL連接請求。當客戶機連接到這個端口上時，它將啟動一次建立 SSL會話的握手。當握手完成之后，通信內(nèi)容被加密，并且執(zhí)行消息完整性檢查，直到 SSL會話過期。 SSL創(chuàng)建一個會話，在此期間，握手必須只發(fā)生過一次。2023/2/27 星期六 39Ch7網(wǎng)絡安全協(xié)議? 步驟 1： SSL客戶機連接到 SSL服務器，并要求服務器驗證它自身的身份。? 步驟 2：服務器通過發(fā)送它的數(shù)字證書證明其身份。這個交換還可以包括整個證書鏈，直到某個根證書權(quán)威機構(gòu) (CA)。 通過檢查有效日期并確認證書包含有可信任 CA的數(shù)字簽名，來驗證證書。? 步驟 3：服務器發(fā)出一個請求，對客戶端的證書進行驗證。但是，因為缺乏公鑰體系結(jié)構(gòu)，當今的大多數(shù)服務器不進行客戶端認證。2023/2/27 星期六 40Ch7網(wǎng)絡安全協(xié)議? 步驟 4：協(xié)商用于加密的消息加密算法和用于完整性檢查的哈希函數(shù)。通常由客戶機提供它支持的所有算法列表，然后由服務器選擇最強健的加密算法。? 步驟 5：客戶機和服務器通過下列步驟生成會話密鑰： ，并使用服務器的公鑰（從服務器的證書中獲得）對它加密，發(fā)送到服務器上。 （從客戶機的密鑰可用時則使用客戶機密鑰；否則以明文方式發(fā)送數(shù)據(jù)）響應。 ，從隨機數(shù)據(jù)生成密鑰。 2023/2/27 星期六 41Ch7網(wǎng)絡安全協(xié)議SSL協(xié)議的優(yōu)點? 機密性 即連接是私有的。在初始握手階段，雙方建立對稱密鑰后，信息即用該密鑰加密。? 完整性 在信息中嵌入信息鑒別碼（ MAC） 來保證信息的完整性。其中使用了安全哈希函數(shù)（例如 SHA和 MD5）來進行 MAC計算。? 鑒別 在握手階段，客戶鑒別服務器用不對稱密鑰或公開密鑰。 2023/2/27 星期六 42Ch7網(wǎng)絡安全協(xié)議SSL協(xié)議的不足? SSL要求 對 每個數(shù)據(jù) 進 行加密和解密操作，因而在帶 來高性能的同 時 ， 對 系 統(tǒng) 也要求高 資 源開 銷 。? SSL協(xié)議 主要是使用公開密 鑰 體制和 證書 技 術(shù) 保 護 信息 傳輸 的機密性和完整性，它不能保 證 信息的不可抵 賴 性，主要適用于點 對 點之 間 的信息 傳輸 ，常用 Web Server方式。? SSL為帶 有安全功能的 TCP/IP套接字 應 用程序接口提供了一個替代的方法，理 論 上，在 SSL之上可以安全方式運行任何原有 TCP/IP應 用程序而不需修改，但 實際 上， SSL目前 還 只是用在 HTTP連 接上。2023/2/27 星期六 43Ch7網(wǎng)絡安全協(xié)議 IPSec協(xié)議 由于協(xié)議 IPv4最初設計時沒有過多地考慮安全性，缺乏對通信雙方真實身份的驗證能力，缺乏對網(wǎng)上傳輸?shù)臄?shù)據(jù)的完整性和機密性保護，并且由于 IP地址可軟件配置等靈活性以及基于源 IP地址的認證機制，使 IP層存在著網(wǎng)絡業(yè)務流易被監(jiān)聽和捕獲、 IP地址欺騙、信息泄漏和數(shù)據(jù)項被篡改等多種攻擊，而 IP是很難抵抗這些攻擊的。 為了實現(xiàn)安全 IP， 因特網(wǎng)工程任務組 IETF于1994年開始了一項 IP安全工程，專門成立了 IP安全協(xié)議工作組 IPSEC， 來制定和推動一套稱為IPSec的 IP安全協(xié)議標準。 2023/2/27 星期六 44Ch7網(wǎng)絡安全協(xié)議IPSec協(xié)議組? 網(wǎng)絡認證協(xié)議 Authentication Header（ AH）? 封裝安全載荷協(xié)議 Encapsulating Security Payload（ ESP）? 密鑰管理