安全通信協(xié)議與交易協(xié)議(編輯修改稿)
2025-01-19 04:22 本頁面
【文章內(nèi)容簡介】 )，要求服務(wù)器的證書中包含了由 CA簽名的 DH公開參數(shù)。客戶或者在證書中提供 DH公開參數(shù)，或者在密鑰交換消息中提供此參數(shù)n EDH(Ephemeral DiffieHellman)，產(chǎn)生臨時(shí)的密鑰， DH公開參數(shù)由發(fā)送者的私鑰進(jìn)行簽名，接收者用對應(yīng)的公鑰進(jìn)行驗(yàn)證n 匿名的 DH， 不加鑒別。會受到中間人攻擊n 然后，指定以下信息n 加密算法和類型 (流還是分組密碼算法 )n HMAC、 MD5還是 SHA1n HashSizen Key Materialn IV Size37第二階段：服務(wù)器鑒別和密鑰交換n 服務(wù)器發(fā)送 certificate消息，消息包含一個(gè) ，或者一條證書鏈n 除了匿名 DH之外的密鑰交換方法都需要n 服務(wù)器發(fā)送 server_key_exchange消息n 可選的，有些情況下可以不需要。只有當(dāng) certificate消息 沒有包含必需的數(shù)據(jù)的時(shí)候才發(fā)送此消息n 消息包含簽名，被簽名的內(nèi)容包括兩個(gè)隨機(jī)數(shù)以及服務(wù)器參數(shù)n 服務(wù)器發(fā)送 certificate_request消息（可選）n 非匿名 server可以向客戶請求一個(gè)證書n 包含證書類型和 CAsn 服務(wù)器發(fā)送 server_hello_done, 然后等待應(yīng)答38第三階段：客戶鑒別和密鑰交換n 客戶收到 server_done消息后，它根據(jù)需要檢查服務(wù)器提供的證書，并判斷 server_hello的參數(shù)是否可以接受，如果都沒有問題的話，發(fā)送一個(gè)或多個(gè)消息給服務(wù)器。n 如果服務(wù)器請求證書的話，則客戶首先發(fā)送一個(gè) certificate消息，若客戶沒有證書，則發(fā)送一個(gè) no_certificate警告 。 然后客戶發(fā)送client_key_exchange消息，消息的內(nèi)容取決于密鑰交換的類型（如果是RSA，則含加密的 PreMasterSecret）。n 最后，客戶發(fā)送一個(gè) certificate_verify消息（可選），其中包含一個(gè)簽名，對從第一條消息以來的所有握手消息的 HMAC值 (用 master_secret)進(jìn)行簽名39第四階段：結(jié)束n 第四階段建立起一個(gè)安全的連接n 客戶發(fā)送一個(gè) change_cipher_spec消息，并且把協(xié)商得到的 CipherSuite拷貝到當(dāng)前連接的狀態(tài)之中n 然后，客戶用本次連接協(xié)商的算法、密鑰參數(shù)發(fā)送一個(gè) finished消息，這條消息可以檢查密鑰交換和鑒別過程是否已經(jīng)成功。其中包括一個(gè)校驗(yàn)值，對所有以來的消息進(jìn)行校驗(yàn)。n 服務(wù)器同樣發(fā)送 change_cipher_spec消息和 finished消息。n 握手過程完成，客戶和服務(wù)器可以交換應(yīng)用層數(shù)據(jù)。40握手協(xié)議過程n 第一階段 安全能力的建立（測試對方是否支持相應(yīng)的安全功能）(1) 客戶 → 服務(wù)器 ： client_hello， 給出選擇列表(2) 服務(wù)器 → 客戶 ： server_hello， 選擇加密、壓縮方法n 第二階段 服務(wù)器認(rèn)證和密鑰交換(3) 服務(wù)器 → 客戶 ： server_certificate， 服務(wù)器的證書(4) 服務(wù)器 → 客戶 ： server_key_exchange，（ 可選）(5) 服務(wù)器 → 客戶 ： certificate_request， 要求客戶出示證書(6) 服務(wù)器 → 客戶 ： server_hello_done， 聲明結(jié)束本階段n 第三階段 客戶認(rèn)證和密鑰交換(7) 客戶 → 服務(wù)器 ： client_certificate， 客戶的證書(8) 客戶 → 服務(wù)器 ： client_key_exchange， 同上，公鑰體系不用(9) 客戶 → 服務(wù)器 ： certificate_verify， 證書檢驗(yàn)（能力確認(rèn)）n 第四階段 結(jié)束階段(10) 客戶 → 服務(wù)器 ： change_cipher_spec。(11) 客戶 → 服務(wù)器 ： finished(12) 服務(wù)器 → 客戶 ： change_cipher_spec。(13) 服務(wù)器 → 客戶 ： finished41SSL的 會話狀態(tài)會話狀態(tài)n 狀態(tài) 參數(shù)：n 會 話標(biāo)識 符 : 服 務(wù) 器 選擇 的一個(gè)任意字 節(jié) 序列，用以 標(biāo)識 一個(gè)活 動(dòng) 的或可激活的會 話 狀態(tài) 。n 對 方的 證書 : 一個(gè) ?？?為 空。n 壓縮 算法 : 加密前 進(jìn) 行數(shù)據(jù) 壓縮 的算法。n 加密 規(guī)約 : 指明數(shù)據(jù)體加密的算法（無，或DES等）以及散列算法（如 MD5或 SHA1）用以計(jì) 算 MAC。 還 包括其他參數(shù)，如散列 長 度。n 主密 值 : 48位秘密，在 client與 server之 間共享。n 可重新開始的 標(biāo) 志 :一個(gè) 標(biāo) 志，指明 該 會 話 是否能用于 產(chǎn) 生一個(gè)新 連 接。42密鑰交換算法n SSL記錄協(xié)議需要： CipherSuite, master secret, the client server random valuesn 在 hello消息中，交換隨機(jī)數(shù)以及各種算法n 兩類密鑰交換算法：n RSA，客戶產(chǎn)生一個(gè) 48字節(jié)的 pre_master_secret，然后通過服務(wù)器的公鑰傳遞給服務(wù)器n DiffieHellman，雙方協(xié)商得到的密鑰被用作pre_master_secretn 對于各種密鑰交換算法，從 pre_master_secret計(jì)算得到Master_secret，然后從內(nèi)存中刪除n Master_secret總是 48字節(jié)長，而 pre_master_secret長度不定，取決于密鑰交換算法43Master_secret的產(chǎn)生n SSL Master_secret =MD5(pre_master_secret‖ SHA1(‘A’‖ pre_master_secret|| ‖ )) ‖MD5(pre_master_secret‖ SHA1(‘BB’‖ pre_master_secret|| ‖ )) ‖MD5(pre_master_secret‖ SHA1(‘CCC’‖ pre_master_secret|| ‖ ))n TLS master_secret = PRF(pre_master_secret, “master secret” , , + )[0..47]* PRF(secret, label, seed)為偽隨機(jī)函數(shù)44會話恢復(fù)n 整個(gè)握手協(xié)議開銷巨大 ,如果集成會話恢復(fù)機(jī)制 ,則可以在客戶和服務(wù)器通信過一次的情況下 ,可以跳過握手階段而直接進(jìn)行數(shù)據(jù)傳輸 .n 通過使用上一次握手中確立的 pre_master_secret,則可以避免許多計(jì)算開銷。n 恢復(fù)允許根據(jù)共同的 master_secret，來產(chǎn)生新的密鑰。n
外語相關(guān)推薦
鄂ICP備17016276號-1