計(jì)算機(jī)網(wǎng)絡(luò)_第六章_安全套接層協(xié)議ssl_77(編輯修改稿)
2025-03-05 16:17 本頁面
【文章內(nèi)容簡介】 (Content)， ≧ 1個(gè)字節(jié)：與此消息有關(guān)的參數(shù)，表 。 SSL握手協(xié)議使用的消息 第一階段：建立起安全協(xié)商 ? 客戶發(fā)送一個(gè) client_hello消息，包括以下參數(shù)：版本、隨機(jī)數(shù) (32位時(shí)間戳 +28字節(jié)隨機(jī)序列 )、會(huì)話 ID、客戶支持的密碼算法列表 (CipherSuite)、客戶支持的壓縮方法列表 , ? 然后，客戶等待服務(wù)器的 server_hello消息 ? 服務(wù)器發(fā)送 server_hello消息，參數(shù)：客戶建議的低版本以及服務(wù)器支持的最高版本、服務(wù)器產(chǎn)生的隨機(jī)數(shù)、會(huì)話 ID、服務(wù)器從客戶建議的密碼算法中挑出一套、服務(wù)器從客戶建議的壓縮方法中挑出一個(gè) . CipherSuite密碼套件 ? 第一個(gè)元素指定了密鑰交換的方法， SSL支持以下一些方法： ? RSA，要求服務(wù)器提供一個(gè) RSA證書 ? DH(DiffieHellman)，要求服務(wù)器的證書中包含了由CA簽名的 DH公開參數(shù)。客戶或者在證書中提供 DH公開參數(shù)，或者在密鑰交換消息中提供此參數(shù) 第二階段：服務(wù)器鑒別和密鑰交換 ? 服務(wù)器發(fā)送自己的證書，消息包含一個(gè) ，或者一條證書鏈 ? 服務(wù)器發(fā)送 server_key_exchange消息 ? 可選的，有些情況下可以不需要。只有當(dāng)服務(wù)器的證書沒有包含必需的數(shù)據(jù)的時(shí)候才發(fā)送此消息 ? 消息包含簽名，被簽名的內(nèi)容包括兩個(gè)隨機(jī)數(shù)以及服務(wù)器參數(shù) ? 服務(wù)器發(fā)送 certificate_request消息 ? 非匿名 server可以向客戶請(qǐng)求一個(gè)證書 ? 包含證書類型和 CAs ? 服務(wù)器發(fā)送 server_hello_done, 然后等待應(yīng)答 第三階段：客戶鑒別和密鑰交換 ? 客戶收到 server_done消息后，它根據(jù)需要檢查服務(wù)器提供的證書，并判斷 server_hello的參數(shù)是否可以接受，如果都沒有問題的話，發(fā)送一個(gè)或多個(gè)消息給服務(wù)器 ? 如果服務(wù)器請(qǐng)求證書的話，則客戶首先發(fā)送一個(gè) certificate消息，若客戶沒有證書，則發(fā)送一個(gè) no_certificate警告 ? 然后客戶發(fā)送 client_key_exchange消息 ? 最后，客戶發(fā)送一個(gè) certificate_verify消息，其中包含一個(gè)簽名，對(duì)從第一條消息以來的所有握手消息的 MAC值 ()進(jìn)行簽名 第四階段：結(jié)束 ? 第四階段建立起一個(gè)安全的連接 ? 客戶發(fā)送一個(gè) change_cipher_spec消息，并且把協(xié)商得到的 CipherSuite拷貝到當(dāng)前連接的狀態(tài)之中 ? 然后，客戶用新的算法、密鑰參數(shù)發(fā)送一個(gè) finished消息，這條消息可以檢查密鑰交換和鑒別過程是否已經(jīng)成功。其中包括一個(gè)校驗(yàn)值，對(duì)所有以來的消息進(jìn)行校驗(yàn)。 ? 服務(wù)器同樣發(fā)送 change_cipher_spec消息和 finished消息。 ? 握手過程完成，客戶和服務(wù)器可以交換應(yīng)用層數(shù)據(jù)。 SSL握手協(xié)議的流程 ? 交換 Hello消息，對(duì)于算法、交換隨機(jī)值等協(xié)商一致 ? 交換必要的密碼參數(shù)，以便雙方得到統(tǒng)一的 premaster secret ? 交換證書和相應(yīng)的密碼信息，以便進(jìn)行身份認(rèn)證 ? 產(chǎn)生 master secret ? 把安全參數(shù)提供給 SSL記錄層 ? 檢驗(yàn)雙方是否已經(jīng)獲得同樣的安全參數(shù) SSL記錄協(xié)議 (SSL Record Protocol) ? SSL記錄協(xié)議為每一個(gè) SSL連接提供以下兩種服務(wù)： ? 機(jī)密性 (Confidentiality)： SSL記錄協(xié)議會(huì)協(xié)助雙方產(chǎn)生一把共有的密鑰，利用這把密鑰來對(duì) SSL所傳送的數(shù)據(jù)做傳統(tǒng)式加密。 ? 消息完整性 (Message Integrity)： SSL記錄協(xié)議會(huì)協(xié)助雙方產(chǎn)生另一把共有的密鑰，利用這把密鑰來計(jì)算出消息認(rèn)證碼。 SSL數(shù)據(jù)單元的形成過程 用戶數(shù)據(jù)單元 分段 壓縮 附加 MAC 加密 附加 SSL報(bào)頭 SSL記錄協(xié)議操作流程 1. 第一個(gè)步驟是分片 (fragmentation)。每個(gè)上層應(yīng)用數(shù)據(jù)被分成 214字節(jié)或更小的數(shù)據(jù)塊。記錄中包含類型、版本號(hào)、長度和數(shù)據(jù)字段 . 2. 選擇是否執(zhí)行壓縮的步驟 (pression)。壓縮的過程中，必須是無損失壓縮 (lossless)，也就是說解壓縮后能夠得到原本完整的消息。經(jīng)過壓縮后的內(nèi)容長度不能超過原有長度 1024字節(jié)以上 ,在 SSLv3（以及 TLS的現(xiàn)有版本），并沒有指定壓縮算法，所以預(yù)設(shè)的算法是 null。 3. 計(jì)算壓縮數(shù)據(jù)的消息認(rèn)證碼 (message authentication code)。為了達(dá)到這個(gè)目的，必須使用一把雙方共有的密鑰。 SSL Record Format SSL協(xié)議采用的加密和認(rèn)證算法 ? 加密算法 塊加密 流加密 加密 算法 密鑰長度 加密算法 密鑰長度 IDEA RC240 DES40 DES 3DES Fortezza 128 40 40 56 168 80 RC440 RC4128 40 128 認(rèn)證算法 認(rèn)證算法采用 ，通過使用 RSA算法進(jìn)行數(shù)字簽名來實(shí)現(xiàn)的。 ? ⑴ 服務(wù)器的認(rèn)證：服務(wù)器方的寫密鑰和客戶方的讀密鑰、客戶方的寫密鑰和服務(wù)器方的讀密鑰分別是一對(duì)私有、公有密鑰。 ? ⑵ 客戶的認(rèn)證： 會(huì)話層的密鑰分配協(xié)議 ? ⑴ SKEIP（ Simple Key Exchange for Inter Protocol）。由公鑰證書來實(shí)現(xiàn)兩個(gè)通信實(shí)體間的長期單鑰的交換。證書通過用戶數(shù)據(jù)協(xié)議 UDP得到 ? ⑵ Photuris。 SKEIP有其不利的一面，若某人能得到長期SKEIP密鑰，他就可以解出所有以前用此密鑰加密的信息，而Photuris只用長期密鑰認(rèn)證會(huì)話密鑰，則無此問題。但Photuris效率沒有 SKEIP高。 ? ⑶ ISAKMP(Inter安全協(xié)會(huì)的密鑰管理協(xié)議 )。和前兩者不同， ISAKMP只提供密鑰管理的一般框架，而不限定密鑰管理協(xié)議，也不限定密鑰算法或協(xié)議，因此在使用和策略上更為靈活。 SSL協(xié)議安全性分析 ? 安全機(jī)制分析 ? ⑴ 鑒別機(jī)制。 公開密鑰技術(shù)和數(shù)字證書可以實(shí)現(xiàn)客戶端和服務(wù)器端的身份鑒別。 ClientHello和ServerHello發(fā)過去自己的證書 (里面包含了身份和自己的公鑰 )。
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號(hào)-1