【正文】 ，直到 SSL會(huì)話過(guò)期。支持 SSL的典型 WEB服務(wù)器在一個(gè)與標(biāo)準(zhǔn) HTTP請(qǐng)求（默認(rèn)為端口 80）不同的端口（默認(rèn)為 443）上接受 SSL連接請(qǐng)求。 兩個(gè)互相不知其代碼的應(yīng)用程序可用 TLS來(lái)安全地通信。 2023/2/27 星期六 37Ch7網(wǎng)絡(luò)安全協(xié)議 TLS協(xié)議 傳輸層安全 TLS(Transport Layer Security)協(xié)議是 IETF正在定義一種新的協(xié)議 。握手協(xié)議 改 變 狀 態(tài) 至 連 接狀 態(tài) 。然后服務(wù)器發(fā)出一個(gè)密文修改規(guī)約信息。應(yīng)該注意這部分工作不是由握手協(xié)議控制，是由修改密文規(guī)約協(xié)議管理的。 然后，客戶(hù)方發(fā)出一個(gè)結(jié)束信息，指出協(xié)商過(guò)程已經(jīng)完成。② 如果服務(wù)器發(fā)送了一個(gè)服務(wù)器密鑰交換信息，那么客戶(hù)方就發(fā)送一個(gè)基于公鑰算法的由 HELLO信息決定的密鑰交換信息。 最后，服務(wù)器發(fā)出一個(gè)服務(wù)器 HELLO DONE信息，開(kāi)始等待客戶(hù)的回音。 ②服務(wù)器密鑰交換信息，如果得不到證書(shū)或證書(shū)僅僅用作簽名的話。2023/2/27 星期六 34Ch7網(wǎng)絡(luò)安全協(xié)議SSL握手的詳細(xì)過(guò)程? 第二步：服務(wù)器評(píng)估客戶(hù)方發(fā)來(lái)的 HELLO信息中的各項(xiàng)參數(shù)，并且返回一個(gè)服務(wù)器方的 HELLO信息，其中含有服務(wù)器選來(lái)用于 SSL會(huì)話的各項(xiàng)參數(shù)（版本號(hào)、時(shí)間信息、以標(biāo)準(zhǔn)的 UNIX32位格式標(biāo)識(shí)的現(xiàn)時(shí)和日期、會(huì)話標(biāo)識(shí)、密文組、壓縮方法、隨機(jī)數(shù)）。⑤ 客戶(hù)方所支持的壓縮算法。③ 會(huì)話標(biāo)識(shí)（可選），如果沒(méi)有指定的話，則服務(wù)器便重用上一次的會(huì)話標(biāo)識(shí)或返回一個(gè)錯(cuò)誤信息④ 密文組（客戶(hù)方所支持的各種加密算法選項(xiàng)清單。這信息包括：① 想要使用的 SSL版本號(hào)。因此在 傳輸 任何 應(yīng) 用數(shù)據(jù)前，都必 須使用握手 協(xié)議 。 2023/2/27 星期六 30Ch7網(wǎng)絡(luò)安全協(xié)議 SSL握手協(xié)議 一個(gè) SSL會(huì)話工作在不同的狀態(tài)，即會(huì)話狀態(tài)和連接狀態(tài)。如果在通信過(guò)程中某一方發(fā)現(xiàn)任何異常，就需要給對(duì)方發(fā)送一條警示消息通告。 SSL告警協(xié)議的每個(gè)報(bào)文由兩個(gè)字節(jié)組成。 2023/2/27 星期六 29Ch7網(wǎng)絡(luò)安全協(xié)議 SSL告警協(xié)議 SSL告警協(xié)議是用來(lái)將 SSL有關(guān)的告警傳送給對(duì)方實(shí)體的。在修改密文規(guī)約的通告發(fā)出以后，客戶(hù)方就發(fā)出一個(gè)握手密鑰交換信息（如果可得到的話），鑒定認(rèn)證信息，服務(wù)器則在處理了密鑰交換信息之后發(fā)送一個(gè)修改密文規(guī)約信息。 2023/2/27 星期六 28Ch7網(wǎng)絡(luò)安全協(xié)議 SSL修改密文規(guī)約協(xié)議 SSL修改密文規(guī)約協(xié)議用來(lái)發(fā)送修改密文規(guī)約協(xié)議信息。⑦ 將結(jié)果傳輸?shù)较聦?。這個(gè)工作是由 SSL記錄協(xié)議完成的。 2023/2/27 星期六 24Ch7網(wǎng)絡(luò)安全協(xié)議 SSL記錄協(xié)議 SSL從應(yīng)用層取得的數(shù)據(jù)需要重定格式（分片、可選的壓縮、應(yīng)用 MAC、 加密等）后才能傳給傳輸層進(jìn)行發(fā)送。會(huì)話定義了加密安全參數(shù)的一個(gè)集合，該集合可以被多個(gè)連接所共享。 SSL連接是點(diǎn)對(duì)點(diǎn)的關(guān)系，每一個(gè)連接與一個(gè)會(huì)話相聯(lián)系。它為 TCP/IP連接提供數(shù)據(jù)加密、服務(wù)器認(rèn)證、消息完整性以及可選的客戶(hù)機(jī)認(rèn)證。傳輸層安全協(xié)議的目的是為了保護(hù)傳輸層的安全，并在傳輸層上提供實(shí)現(xiàn)保密、認(rèn)證和完整性的方法。? Kerberos存在的問(wèn)題：① Kerberos服務(wù)器的損壞將使得整個(gè)安全系統(tǒng)無(wú)法工作；② AS在傳輸用戶(hù)與 TGS間的會(huì)話密鑰時(shí)是以用戶(hù)密鑰加密的，而用戶(hù)密鑰是由用戶(hù)口令生成的，因此可能受到口令猜測(cè)的攻擊；③ Kerberos使用了時(shí)間戳，因此存在時(shí)間同步問(wèn)題；④ 要將 Kerberos用于某一應(yīng)用系統(tǒng)，則該系統(tǒng)的客戶(hù)端和服務(wù)器端軟件都要作一定的修改。據(jù)此，用戶(hù)可以驗(yàn)證應(yīng)用服務(wù)器的合法性。 ? ⑥ 應(yīng)用服務(wù)器從許可證中取出會(huì)話密鑰、解密認(rèn)證符，取出時(shí)間戳并檢驗(yàn)有效性。 TGS將應(yīng)用服務(wù)器的許可證和會(huì)話密鑰傳回到用戶(hù)。 2023/2/27 星期六 19Ch7網(wǎng)絡(luò)安全協(xié)議? ④ TGS從許可證中取出會(huì)話密鑰、解密認(rèn)證符，驗(yàn)證認(rèn)證符中時(shí)間戳的有效性，從而確定用戶(hù)的請(qǐng)求是否合法。 ? ③ 用戶(hù)解密得到 TGS的響應(yīng)，然后利用 TGS的許可證向 TGS申請(qǐng)應(yīng)用服務(wù)器的許可證，該申請(qǐng)包括TGS的許可證和一個(gè)帶有時(shí)間戳的認(rèn)證符（authenticator）。 ? ② AS以證書(shū)（ credential） 作為響應(yīng)，證書(shū)包括訪問(wèn) TGS的許可證和用戶(hù)與 TGS間的會(huì)話密鑰。用戶(hù)在對(duì)應(yīng)用服務(wù)器進(jìn)行訪問(wèn)之前，必須先從第三方（Kerberos 服務(wù)器）獲取該應(yīng)用服務(wù)器的訪問(wèn)許可證（ ticket）。? Credentials（ 證書(shū)） 由一個(gè) ticket加上一個(gè)秘密的會(huì)話密鑰組成。 Ticket中的大多數(shù)信息都被加密，密鑰為服務(wù)器的密鑰。? KDC(Key distribution center， 密鑰分配中心 ) 可信的第三方，即 Kerberos服務(wù)器，提供ticket和臨時(shí)的會(huì)話密鑰。 Kerberos一詞源自希臘神話，在希臘神話故事中， Kerberos是一種長(zhǎng)有三個(gè)頭的狗，還有一個(gè)蛇形尾巴，是地獄之門(mén)的守衛(wèi)者。 如何使用一個(gè)集中的認(rèn)證服務(wù)器，提供用戶(hù)對(duì)服務(wù)器的認(rèn)證以及服務(wù)器對(duì)用戶(hù)的認(rèn)證，這就是 Kerberos要解決的問(wèn)題。 2023/2/27 星期六 12Ch7網(wǎng)絡(luò)安全協(xié)議? 另一方面，在開(kāi)放的網(wǎng)絡(luò)環(huán)境中，客戶(hù)也必須防止來(lái)自服務(wù)端的欺騙。 ② 用戶(hù)可能會(huì)更改工作站的網(wǎng)絡(luò)地址，使從這個(gè)已更改的工作站上發(fā)出的請(qǐng)求看似來(lái)自偽裝的工作站。? 標(biāo)號(hào) 4表示 B把用 A的密鑰加密的消息連同索引號(hào) R一起傳給 A。A BS12342023/2/27 星期六 10Ch7網(wǎng)絡(luò)安全協(xié)議? 標(biāo)號(hào) 3表示 S檢查兩個(gè)加密部分中的索引號(hào) R是否相同，如果相同，就認(rèn)為從 B來(lái)的消息是有效的。? 標(biāo)號(hào) 2表示 B用 A消息中的加密部分構(gòu)造一條新消息。 T記錄了認(rèn)證服務(wù)器 S發(fā)送消息 (2)時(shí)的時(shí)間， A、 B根據(jù)時(shí)間戳驗(yàn)證消息的 “ 新鮮性 ” ，從而避免了重放攻擊。 H截獲之，并用 Kab 解密得到此隨機(jī)量，然后向 B返回一個(gè)響應(yīng)消息，使得 B相信他正在用會(huì)話密鑰 Kab與 A通訊，而實(shí)際上 A根本沒(méi)有參加這一輪協(xié)議的運(yùn)行。 B無(wú)法知道這是不是一個(gè) A發(fā)送的正常通訊請(qǐng)求，也不記得他過(guò)去曾經(jīng)用過(guò) Kab作為會(huì)話密鑰。 A BS13452(1) A ? S： A,B,Na(2)S ? A： {Na, B,Kab,{Kab, A}Kbs}Kas(3) A ? B： {Kab,A}Kbs(4) B ? A： {Nb}Kab(5) A ? B： {Nb1}Kab2023/2/27 星期六 7Ch7網(wǎng)絡(luò)安全協(xié)議 NeedhaulScllroeder共享密鑰協(xié)議的漏洞 假定有攻擊者 H記錄下 A與 B之間執(zhí)行 NeedhamSchroeder 共享密鑰協(xié)議的一輪消息，并且進(jìn)而破獲了其會(huì)話密鑰 Kab （如經(jīng)過(guò)蠻力攻擊等），攻擊者可以在第 3步冒充 A利用舊的會(huì)話密鑰欺騙 B。 Kab 是認(rèn)證服務(wù)器臨時(shí)生成的密鑰，用于 A、 B雙方認(rèn)證之后的加密通訊，稱(chēng)為會(huì)話密鑰。 協(xié)議涉及三個(gè)主體： A和 B， 以及 A， B信賴(lài)的可信第三方，也叫認(rèn)證服務(wù)器(authentication server)S。 ? OtwayRees協(xié)議 OtwayRees協(xié)議的主要功能是完成身份的雙向認(rèn)證，使用對(duì)稱(chēng)密碼。 2023/2/27 星期六 3Ch7網(wǎng)絡(luò)安全協(xié)議? 網(wǎng)絡(luò)層的安全協(xié)議： IPSec? 傳輸層的安全協(xié)議： SSL/TLS? 應(yīng)用層的安全協(xié)議 ： SHTTP（ Web安全協(xié)議） PGP(電子郵件安全協(xié)議 ) S/MIME(電子郵件安全協(xié)議 ) MOSS(電子郵件安全協(xié)議 ) PEM(電子郵件安全協(xié)議 ) SSH（ 遠(yuǎn)程登錄安全協(xié)議）