8- network security protocol (2)

網(wǎng)絡(luò)安全協(xié)議 SSL SET 2 網(wǎng)絡(luò)安全協(xié)議 ssl 3 網(wǎng)絡(luò)安全協(xié)議 ssl Web的安全 Web是一個運行于internet和TCP IPintranet之上的基本的client server應用 Web安全性涉及前面討論的所有計算機與網(wǎng)絡(luò)的安全性內(nèi)容 同時還具有新的挑戰(zhàn) Web具有雙向性 Webserver易于遭受來自Internet的攻擊Web越來越多地作為商業(yè)合作和產(chǎn)品信息的發(fā)布窗口和商務(wù)交易平臺 Webserver可能發(fā)生信譽受損和金錢失竊等問題實現(xiàn)Web瀏覽 配置管理 內(nèi)容發(fā)布等功能的軟件異常復雜 其中隱藏許多潛在的安全隱患 Web通常是一個公司或機構(gòu)的發(fā)布板 常常和其它計算機聯(lián)系在一起 一旦Webserver被攻破 可能殃及其它 用戶往往是偶然的和未經(jīng)訓練的 對安全風險沒有意識 更沒有足夠的防范工具和知識 4 網(wǎng)絡(luò)安全協(xié)議 ssl Web安全性威脅與對策 拒絕服務(wù)攻擊 認證 5 網(wǎng)絡(luò)安全協(xié)議 ssl Web安全性方法 6 網(wǎng)絡(luò)安全協(xié)議 ssl SSL TLS協(xié)議 1994年Netscape開發(fā)了SSL SecureSocketLayer 安全套接層協(xié)議 專門用于保護Web通訊版本和歷史1 0 不成熟2 0 基本上解決了Web通訊的安全問題Microsoft公司發(fā)布了PCT PrivateCommunicationTechnology 并在IE中支持3 0 1996年發(fā)布 增加了一些算法 修改了一些缺陷TLS1 0 TransportLayerSecurity傳輸層安全協(xié)議 也被稱為SSL3 1 1997年IETF發(fā)布了Draft 同時 Microsoft宣布放棄PCT 與Netscape一起支持TLS1 01999年 發(fā)布RFC2246 TheTLSProtocolv1 0 7 網(wǎng)絡(luò)安全協(xié)議 ssl 協(xié)議的目標 目標 SSL被設(shè)計用來使用TCP提供一個可靠的端到端安全服務(wù) 為兩個通訊個體之間提供保密性和完整性 身份認證 8 網(wǎng)絡(luò)安全協(xié)議 ssl 協(xié)議的使用 https 與shttp 9 網(wǎng)絡(luò)安全協(xié)議 ssl SSL體系結(jié)構(gòu) 協(xié)議分為兩層底層 SSL記錄協(xié)議上層 SSL握手協(xié)議 SSL修改密碼規(guī)范協(xié)議 SSL警報協(xié)議 10 網(wǎng)絡(luò)安全協(xié)議 ssl 兩個主要的協(xié)議 SSL記錄協(xié)議建立在可靠的傳輸協(xié)議 如TCP 之上它提供連接安全性 有兩個特點保密性 使用了對稱加密算法完整性 使用HMAC算法用來封裝高層的協(xié)議SSL握手協(xié)議客戶和服務(wù)器之間相互認證協(xié)商加密算法和密鑰它提供連接安全性 有三個特點身份認證 至少對一方實現(xiàn)認證 也可以是雙向認證協(xié)商得到的共享密鑰是安全的 中間人不能夠知道協(xié)商過程是可靠的 11 網(wǎng)絡(luò)安全協(xié)議 ssl SSL的兩個重要概念 SSL連接 connection 一個連接是一個提供一種合適類型服務(wù)的傳輸 OSI分層的定義 SSL的連接是點對點的關(guān)系 連接是暫時的 每一個連接和一個會話關(guān)聯(lián) SSL會話 session 一個SSL會話是在客戶與服務(wù)器之間的一個關(guān)聯(lián) 會話由握手創(chuàng)建 會話定義了一組可供多個連接共享的密碼安全參數(shù) 會話用以避免為每一個連接提供新的安全參數(shù)所需昂貴的協(xié)商代價 12 網(wǎng)絡(luò)安全協(xié)議 ssl 會話狀態(tài) 有多個狀態(tài)與每一個會話相關(guān)聯(lián)一旦一個會話建立 就存在一個讀或?qū)懙漠斍盃顟B(tài)在握手協(xié)議中 創(chuàng)建了掛起的讀寫狀態(tài)成功的握手協(xié)議 將掛起狀態(tài)轉(zhuǎn)變?yōu)楫斍盃顟B(tài) 13 網(wǎng)絡(luò)安全協(xié)議 ssl 會話狀態(tài)參數(shù) 會話標識 服務(wù)器選擇的一個任意字節(jié)序列 用以標識一個活動的或可激活的會話狀態(tài) 同位體證書 一個X 509 v3證書 可為空 壓縮方法 加密前進行數(shù)據(jù)壓縮的算法 密碼規(guī)范 指明數(shù)據(jù)體加密的算法 無 或DES等 以及散列算法 如MD5或SHA 1 用以計算MAC 還包括其它參數(shù) 如散列長度 主密碼 48位秘密 在client與server之間共享 可恢復性 一個標志 指明該會話是否能用于產(chǎn)生一個新連接 14 網(wǎng)絡(luò)安全協(xié)議 ssl 連接狀態(tài) 服務(wù)器和客戶端隨機數(shù) server和client為每一個連接所選擇的字節(jié)序列 服務(wù)器寫MAC密碼 一個密鑰 用來對server送出的數(shù)據(jù)進行MAC操作 客戶端寫MAC密碼 一個密鑰 用來對client送出的數(shù)據(jù)進行MAC操作 服務(wù)器寫密鑰 用于server進行數(shù)據(jù)加密 client進行數(shù)據(jù)解密的對稱保密密鑰 客戶端寫密鑰 用于client進行數(shù)據(jù)加密 server進行數(shù)據(jù)解密的對稱保密密鑰 初始化向量 當數(shù)據(jù)加密采用CBC方式時 每一個密鑰保持一個IV 該字段首先由SSL握手協(xié)議 以后保留每次最后的密文數(shù)據(jù)塊作為IV 序列號 每一方為每一個連接的數(shù)據(jù)發(fā)送與接收維護單獨的順序號 當一方發(fā)送或接收一個修改密碼規(guī)范協(xié)議報文時 序號置為0 最大264 1 15 網(wǎng)絡(luò)安全協(xié)議 ssl SSL記錄協(xié)議 SSL記錄協(xié)議為SSL連接提供兩種服務(wù)保密性 握手定義一個共享的保密密鑰用于對SSL有效載荷加密 消息完整性 握手定義一個共享的保密密鑰用于形成MAC 16 網(wǎng)絡(luò)安全協(xié)議 ssl SSL記錄協(xié)議 操作過程示意圖 17 網(wǎng)絡(luò)安全協(xié)議 ssl SSL記錄協(xié)議中的操作 第一步 fragmentation分段上層消息的數(shù)據(jù)被分片成214 16384 字節(jié)大小的塊 或者更小第二步 compression 可選 壓縮必須是無損壓縮 如果數(shù)據(jù)增加的話 則增加部分的長度不超過1024字節(jié) 18 網(wǎng)絡(luò)安全協(xié)議 ssl 第三步 MAC計算 使用共享的密鑰MAC write secrethash MAC write seret pad 2 hash MAC write secret pad 1 seq num SSLCompressed type SSLCompressed length SSLCompressed fragment 其中 MAC write secret 共享的保密密鑰hash 密碼散列函數(shù) MD5或SHA 1 pad 1 0 x36重復48次 MD5 或40次 SHA 1 pad 2 0 x5C重復48次 MD5 或40次 SHA 1 seq num 該消息的序列號SSLCompressed type 用于處理本分段的上層協(xié)議SSLCompressed length 壓縮分段的長度SSLCompressed fragment 壓縮的分段 無壓縮時為明文段 19 網(wǎng)絡(luò)安全協(xié)議 ssl 第四步 加密 可供選擇的加密算法 IDEA128RC 4040RC2 4040RC4 128128DES 4040DES563DES168Fortezza 智能卡加密 80 采用CBC 算法由密碼規(guī)范指定 數(shù)據(jù)長度不超過214 2048字節(jié) 包括IV 初始協(xié)商指定 以后 前后記錄連接起來說明 如果是流密碼算法 則不需要填充 20 網(wǎng)絡(luò)安全協(xié)議 ssl SSL記錄格式 內(nèi)容類型 8位 上層協(xié)議類型主版本 從版本 16位壓縮長度 16位 加密后數(shù)據(jù)的長度 不超過214 2048字節(jié)EncryptedDatafragment 密文數(shù)據(jù) 21 網(wǎng)絡(luò)安全協(xié)議 ssl SSL修改密碼協(xié)議和警報協(xié)議 修改密碼協(xié)議 僅包含一個字節(jié)的值為1的消息 使得掛起狀態(tài)被拷貝到當前狀態(tài)中 用于更新此連接使用的密碼組用于向?qū)Φ葘嶓w傳遞SSL相關(guān)的警報 由兩個字節(jié)組成 值1表示警告 值2表示致命錯誤來傳遞消息出錯的嚴重程度SSL記錄協(xié)議的有效載荷如下圖 22 網(wǎng)絡(luò)安全協(xié)議 ssl SSL握手協(xié)議流程 交換Hello消息 對于算法 交換隨機值等協(xié)商一致交換必要的密碼參數(shù) 以便雙方得到統(tǒng)一的premastersecret交換證書和相應的密碼信息 以便進行身份認證產(chǎn)生mastersecret把安全參數(shù)提供給SSL記錄層檢驗雙方是否已經(jīng)獲得同樣的安全參數(shù) 23 網(wǎng)絡(luò)安全協(xié)議 ssl SSL握手協(xié)議使用的消息 24 網(wǎng)絡(luò)安全協(xié)議 ssl 第一階段 建立起安全協(xié)商 客戶發(fā)送一個client hello消息 包括以下參數(shù) 版本 隨機數(shù) 32位時間戳 28字節(jié)隨機序列 會話ID 客戶支持的密碼算法列表 CipherSuite 客戶支持的壓縮方法列表然后 客戶等待服務(wù)器的server hello消息服務(wù)器發(fā)送server hello消息 參數(shù) 客戶建議的低版本以及服務(wù)器支持的最高版本 服務(wù)器產(chǎn)生的隨機數(shù) 會話ID 服務(wù)器從客戶建議的密碼算法中挑出一套 服務(wù)器從客戶建議的壓縮方法中挑出一個 25 網(wǎng)絡(luò)安全協(xié)議 ssl CipherSuite 第一個元素指定了密鑰交換的方法 SSL支持以下一些方法 RSA 要求服務(wù)器提供一個RSA證書DH Diffie Hellman 要求服務(wù)器的證書中包含了由CA簽名的DH公開參數(shù) 客戶或者在證書中提供DH公開參數(shù) 或者在密鑰交換消息中提供此參數(shù)EDH EphemeralDiffie Hellman 產(chǎn)生臨時的密鑰 DH公開參數(shù)由發(fā)送者的私鑰進行簽名 接收者用對應的公鑰進行驗證匿名的DH 不加認證 會受到中間人攻擊然后 指定以下信息 cipherspec 加密算法 和類型 流還是分組密碼算法 HMAC算法 MD5還是SHA 1是否可出口HashSizeKeyMaterialIVSize 26 網(wǎng)絡(luò)安全協(xié)議 ssl 第二階段 服務(wù)器認證和密鑰交換 服務(wù)器發(fā)送自己的證書 消息包含一個X 509證書 或者一條證書鏈除了匿名DH之外的密鑰交換方法都需要服務(wù)器發(fā)送server key exchange消息可選的 有些情況下可以不需要 只有當服務(wù)器的證書沒有包含必需的數(shù)據(jù)的時候才發(fā)送此消息消息包含簽名 被簽名的內(nèi)容包括兩個隨機數(shù)以及服務(wù)器參數(shù)服務(wù)器發(fā)送certificate request消息非匿名server可以向客戶請求一個證書包含證書類型和CAs服務(wù)器發(fā)送server hello done 然后等待應答 27 網(wǎng)絡(luò)安全協(xié)議 ssl 第三階段 客戶認證和密鑰交換 客戶收到server done消息后 它根據(jù)需要檢查服務(wù)器提供的證書 并判斷server hello的參數(shù)是否可以接受 如果都沒有問題的話 發(fā)送一個或多個消息給服務(wù)器如果服務(wù)器請求證書的話 則客戶首先發(fā)送一個certificate消息 若客戶沒有證書 則發(fā)送一個no certificate警告然后客戶發(fā)送client key exchange消息 消息的內(nèi)容取決于密鑰交換的類型最后 客戶發(fā)送一個certificate verify消息 其中包含一個簽名 對從第一條消息以來的所有握手消息的HMAC值 用master secret 進行簽名 28 網(wǎng)絡(luò)安全協(xié)議 ssl 第四階段 結(jié)束 第四階段建立起一個安全的連接客戶發(fā)送一個change cipher spec消息 并且把協(xié)商得到的CipherSuite拷貝到當前連接的狀態(tài)之中然后 客戶用新的算法 密鑰參數(shù)發(fā)送一個finished消息 這條消息可以檢查密鑰交換和認證過程是否已經(jīng)成功 其中包括一個校驗值 對所有以來的消息進行校驗 服務(wù)器同樣發(fā)送change cipher spec消息和finished消息 握手過程完成 客戶和服務(wù)器可以交換應用層數(shù)據(jù) 29 網(wǎng)絡(luò)安全協(xié)議 ssl 密鑰交換算法 SSL記錄協(xié)議需要 CipherSuite mastersecret andtheclientandserverrandomvalues在hello消息中 交換隨機數(shù)以及各種算法兩類密鑰交換算法 RSA 客戶產(chǎn)生一個48字節(jié)的pre master secret 然后通過服務(wù)器的公鑰傳遞給服務(wù)器Diffie Hellman 雙方協(xié)商得到的密鑰被用作pre master secret對于各種密鑰交換算法 從pre master secret計算得到master secret 然后從內(nèi)存中刪除Master secret總是48字節(jié)長 而pre master secret長度不定 取決于密鑰交換算法 30 網(wǎng)絡(luò)安全協(xié)議 ssl 重用一個SSL會話 客戶和服務(wù)器在交換hello消息中 客戶要求重用已有的SSL會話 服務(wù)器同意使用cache中的會話 sessionid跳過第二第三階段 直接把SSL會話中的參數(shù)傳遞給SSL記錄層 31 網(wǎng)絡(luò)安全協(xié)議 ssl SET 32 網(wǎng)絡(luò)安全協(xié)議 ssl 安全電子交易SET 開發(fā)的加密和安全規(guī)范保護互聯(lián)網(wǎng)信用卡交易1996年由Mastercard和Visa提出不是一個支付系統(tǒng)而是一個安全協(xié)議和格式集為交易各方提供安全的信道通過使用x 509v3數(shù)字證書提供信任由于信息只在需要的時間和地方提供 因而要確保私密性 33 網(wǎng)絡(luò)安全協(xié)議 ssl SET的主要特性 信息保密性 持卡人帳號和支付信息在網(wǎng)絡(luò)傳輸過程中是安全的 數(shù)據(jù)完整性 持卡人發(fā)往商家的信息包括訂購信息 個人數(shù)據(jù)和支付指令在傳輸中不被改變持卡人帳號認證 商家要能夠驗證持卡人是否為合法卡帳號的合法用戶商家認證 持卡人要能夠驗證商家是否與允許接收支付卡的金融機構(gòu)建立了聯(lián)系 34 網(wǎng)絡(luò)安全協(xié)議 ssl SET組件 35 網(wǎng)絡(luò)安全協(xié)議 ssl SETTransaction 顧客開通帳號顧客收到證書商家擁有他們自己的證書顧客進行訂購商家被驗證發(fā)送訂購和付款信息商家請求付款認證商家確認訂購商家提供商品和服務(wù)商家請求付款 36 網(wǎng)絡(luò)安全協(xié)議 ssl 雙向簽名 顧客創(chuàng)建雙向信息訂購信息OI給商家付款信息 PI 給銀行商家不需要知道客戶的信用卡號 銀行不需要知道客戶訂購的細節(jié)butmustknowtheyarelinkedusea雙向簽名 dualsignature forthis signedconcatenatedhashesofOI PI 37 網(wǎng)絡(luò)安全協(xié)議 ssl 支付處理