第六章IP與路由安全內(nèi)容提綱IPsec2

IPv6協(xié)議及其安全性分析3路由安全4

IPv4協(xié)議及其安全性分析1IPv4安全性分析IPv4協(xié)議沒有認證機制：沒有消息源認證：源地址假冒沒有完整性認證：篡改IPv4安全性分析IPv4協(xié)議沒有認證機制：沒有消息源認證：源地址假冒沒有完整性認證：篡改IPv4安全性分析IPv4協(xié)議沒有認證機制：沒有消息源認證：源地址假冒沒有完整性認證：篡改IPv4安全性分析IPv4協(xié)議沒有認證機制：沒有消息源認證：源地址假冒沒有完整性認證：篡改IPv4沒有加密機制無機密性：監(jiān)聽?wèi)?yīng)用數(shù)據(jù)泄露拓撲等信息：網(wǎng)絡(luò)偵察無帶寬控制：DDoS攻擊IPv4內(nèi)容提綱IPsec2

IPv6協(xié)議及其安全性分析3路由安全4

IPv4協(xié)議及其安全性分析1IPsec

(IPSecurity)端到端的確保IP通信安全：認證、加密及密鑰管理為IPv6制定（必選），支持IPv4（可選）IPsecIPsec標(biāo)準(zhǔn)內(nèi)容IPsecIPSec安全體系A(chǔ)H協(xié)議ESP協(xié)議加密算法驗證算法DOI密鑰管理（IKE協(xié)議）RFC4301RFC4303RFC4302RFC5996IPsec標(biāo)準(zhǔn)內(nèi)容IPsecIPsec標(biāo)準(zhǔn)內(nèi)容IPsec通過允許系統(tǒng)選擇所需的安全協(xié)議（AH協(xié)議或ESP協(xié)議），決定服務(wù)所使用的加密或認證算法，提供任何服務(wù)需要的密鑰來提供IP級的安全服務(wù)。RFC4301中列出的安全服務(wù)包括：訪問控制、無連接完整性、數(shù)據(jù)源認證、重放檢測與拒絕（部分順序完整性）、保密性（通過加密）以及有限的流量保密性IPsec一、IPsec安全策略IPsec操作的基礎(chǔ)是應(yīng)用于每一個從源端到目的端傳輸?shù)腎P包上的安全策略。IPsec安全策略主要由兩個交互的數(shù)據(jù)庫，安全關(guān)聯(lián)數(shù)據(jù)庫（SecurityAssociationDatabase,SAD）和安全策略數(shù)據(jù)庫（SecurityPolicyDatabase,SPD)來確定安全策略IPsec操作的基礎(chǔ)是應(yīng)用于每一個從源端到目的端傳輸?shù)腎P包上的安全策略。安全策略IKEv2SPD安全策略數(shù)據(jù)庫SAD密鑰交換安全關(guān)聯(lián)數(shù)據(jù)庫IKE

SAIPsecv3SAD安全關(guān)聯(lián)數(shù)據(jù)庫IPsecv3IKEv2SPD安全策略數(shù)據(jù)庫IPsecSA對ESP保護數(shù)據(jù)IPsec安全體系安全關(guān)聯(lián)（SecurityAssociation,SA）一個SA：發(fā)送端和接收端之間的單向邏輯連接，為數(shù)據(jù)流提供安全服務(wù)；經(jīng)過同一SA的數(shù)據(jù)流會得到相同的安全服務(wù)，如AH或ESPSA對：雙向安全數(shù)據(jù)交換同時支持AH、ESP且雙向：需兩對SA安全關(guān)聯(lián)SA一個SA由以下參數(shù)確定安全參數(shù)索引（SecurityParametersIndex,SPI）：32位，，接收方根據(jù)SPI選擇合適的SA處理接收到的數(shù)據(jù)包IP目的地址：僅允許單播地址安全協(xié)議標(biāo)識（SecurityProtocolIdentifier）：AH

/ESP安全關(guān)聯(lián)SASAD定義了所有SA相關(guān)的參數(shù)，每個SA：安全參數(shù)索引序列號計算器序列計數(shù)器溢出反重放窗口AH信息ESP信息安全關(guān)聯(lián)的生存期IPsec協(xié)議模式：：隧道、傳輸或通配符最大傳輸單元路徑（pathMTU）安全關(guān)聯(lián)SASAD定義了所有SA相關(guān)的參數(shù)，每個SA：安全關(guān)聯(lián)SA不同SA可以用多種方式組合以獲得理想的用戶配置。此外，IPsec對需要IPsec保護的流量和不需要IPsec保護的流量提供多種粒度的控制安全關(guān)聯(lián)SA安全策略（SecurityPolicy,SP）指定對IP數(shù)據(jù)包提供何種保護，并以何種方式實施保護主要根據(jù)源IP、目的IP、入數(shù)據(jù)還是出數(shù)據(jù)等來標(biāo)識用戶設(shè)定自己的安全策略的粒度：IP地址，傳輸層協(xié)議，TCP/UDP端口號操作：Discard、Bypass、Protect安全策略SPSPD中的每一條SP包括：本地IP遠程IP下一層協(xié)議名稱本地或遠程端口安全策略SP基于SAD和SPD，IPsec對IP包的處理IP包處理過程

外向IP包（來自TCP或UDP）丟棄報文查詢SPD確定策略發(fā)現(xiàn)匹配丟棄查詢SAD保護網(wǎng)絡(luò)密鑰交換無匹配匹配處理(AH/ESP)通過IP傳輸報文通過無匹配外向(Outboud)IP包處理過程基于SAD和SPD，IPsec對IP包的處理IP包處理過程內(nèi)向(Inboud)IP包處理過程將報文傳輸?shù)缴蠈樱ㄈ鏣CP、UDP）查詢SPD丟棄

報文查詢SAD報文類型不通過處理(AH/ESP)匹配無匹配IPIPsec

內(nèi)向IP包（來自因特網(wǎng)）通過二、IPsec運行模式兩種模式：傳輸模式和隧道模式IPsec運行模式傳輸模式隧道模式傳輸模式和隧道模式比較三、AH協(xié)議學(xué)習(xí)AH和ESP要關(guān)注以下幾個問題:加密、認證的范圍（即對IP協(xié)議報文的哪些部分進行保護）傳輸模式與隧道模式在保護對象、性能、適用場景等方面的差別與NAT的兼容性問題AH協(xié)議AH協(xié)議功能：IP包的數(shù)據(jù)完整性、數(shù)據(jù)來源認證和抗重放攻擊服務(wù)完整性：采用HMAC算法：HMAC-MD5（必須）、HMAC-SHA1（必須）、HAMC-RIPEMD-160等抗重放：序列號AH協(xié)議AH首部AH協(xié)議下一個首部

認證數(shù)據(jù)（變長）載荷長度保留SPI

序列號

071531AH運行模式：傳輸模式AH協(xié)議IP首部（含選項字段）TCP首部（含選項字段）數(shù)據(jù)IP首部（含選項字段）TCP首部（含選項字段）數(shù)據(jù)AH首部認證區(qū)域（可變字段除外）（a）應(yīng)用AH之前（b）應(yīng)用AH（傳輸模式）之后AH運行模式：傳輸模式AH協(xié)議AH運行模式：隧道模式AH協(xié)議IP首部（含選項字段）TCP首部（含選項字段）數(shù)據(jù)IP首部（含選項字段）TCP首部（含選項字段）數(shù)據(jù)AH首部認證區(qū)域（可變字段除外）（a）應(yīng)用AH之前（b）應(yīng)用AH（隧道模式）之后新IP首部（含選項字段）AH運行模式：隧道模式AH協(xié)議抗重放攻擊：序列號+滑動窗口機制AH協(xié)議…NN+1N－

W接收到有效包時標(biāo)記未接收到有效包時不標(biāo)記固定窗口大小W若接收到右邊的有效包，則窗口前進完整性檢驗算法：在SA中指定AH協(xié)議完整性檢驗?zāi)男┳侄螀⑴c計算？如何處理IPv4和IPv6首部中的三種字段：不變字段，可變但可預(yù)測字段，可變不可預(yù)測字段？AH協(xié)議完整性檢驗值ICVIPv4首部三種字段：AH協(xié)議完整性檢驗值ICVIPv6基本首部三種字段：IPv6擴展首部三種字段：AH協(xié)議討論：AH傳輸模式和隧道模式的區(qū)別AH與NAT的兼容性問題AH協(xié)議四、ESP協(xié)議ESP協(xié)議功能：除了提供IP包的數(shù)據(jù)完整性、數(shù)據(jù)來源認證和抗重放攻擊服務(wù)，還提供數(shù)據(jù)包加密和數(shù)據(jù)流加密服務(wù)完整性：采用HMAC算法：HMAC-MD5（必須）、HMAC-SHA1（必須）、HAMC-RIPEMD-160，NULL（無認證）等；ESP認證的數(shù)據(jù)范圍要小于AH協(xié)議加密：對稱密碼，必須支持：DES-CBC和NULL算法（認證和加密不能同時為NULL）ESP協(xié)議ESP首部ESP協(xié)議填充長度

載荷數(shù)據(jù)（變長）填充（0～255字節(jié)）SPI

序列號

071531

認證數(shù)據(jù)（變長）

下一個首部ESP運行模式：傳輸模式ESP協(xié)議ESP運行模式：傳輸模式ESP協(xié)議ESP運行模式：傳輸模式ESP協(xié)議ESP運行模式：傳輸模式ESP協(xié)議ESP協(xié)議ESP運行模式：隧道模式ESP協(xié)議ESP運行模式：隧道模式ESP協(xié)議ESP運行模式：隧道模式ESP協(xié)議討論：ESP傳輸模式和隧道模式的區(qū)別ESP傳輸模式下：如果修改了IP包的首部，IPsec是否能檢測出來這種修改ESP與NAT的兼容性問題ESP與AH的區(qū)別ESP協(xié)議ESP傳輸模式與隧道模式對比隧道模式對整個IP包進行認證和加密，因此可以提供數(shù)據(jù)流加密服務(wù)，而傳輸模式由于IP包首部不被加密，因此無法提供數(shù)據(jù)流加密服務(wù)。但是，隧道模式由于增加了一個新IP首部，降低了鏈路的帶寬利用率。傳輸模式適合于保護支持ESP協(xié)議的主機之間的通信連接，而隧道模式則在包含防火墻或其它用于保護可信內(nèi)網(wǎng)不受外網(wǎng)攻擊的安全網(wǎng)關(guān)的配置中比較有效ESP協(xié)議與NAT兼容問題：AH與NAT不兼容，而ESP不對IP包首部（含選項字段）進行認證，因此不存在和NAT不兼容的問題。如果通信的任何一方具有私有地址或在安全網(wǎng)關(guān)后面，仍然可以用ESP來保護其安全，因為NAT網(wǎng)關(guān)或安全網(wǎng)關(guān)可以修改IP首部中的源／目的IP地址來確保雙方的通信不受影響ESP協(xié)議AH與ESP比較ESP協(xié)議ESP與AH比較

IPsec體系結(jié)構(gòu)文檔中指出，當(dāng)兩個傳輸模式SA被綁定，在同一個端對端流中允許AH和ESP兩種協(xié)議，但認為只有先施ESP協(xié)議再實施AH協(xié)議才合適，為什么？討論五、網(wǎng)絡(luò)密鑰交換IPsec支持以下兩種密鑰管理方式：手動（manual）：管理員為每個系統(tǒng)手動配置所需密鑰，只適用于規(guī)模相對較小且結(jié)點配置相對穩(wěn)定的環(huán)境自動（automated）：系統(tǒng)通過IKE（InternetKeyExchange）協(xié)議自動為SA創(chuàng)建密鑰，適用于大型分布式系統(tǒng)中的密鑰管理IPsec密鑰管理IKEv1：默認的IPsec自動型密鑰管理協(xié)議是ISAKMP/Oakley，包括：互聯(lián)網(wǎng)安全關(guān)聯(lián)和密鑰管理協(xié)議（InternetSecurityAssociationandKeyManagementProtocol,ISAKMP）Oakley密鑰確定協(xié)議（OakleyKeyDeterminationProtocol），基于Diffie-Hellman算法的密鑰交換協(xié)議IKE在IKEv2中，不再使用術(shù)語ISAKMP和Oakley，并且對ISAKMP和Oakley的使用方式也發(fā)生了變化，但是基本功能還是相同的。后面介紹的內(nèi)容是IKEv2IKEDiffie-Hellman回顧兩個優(yōu)點：①僅當(dāng)需要時才生成密鑰，減小了將密鑰存儲很長一段時間而致使遭受攻擊的機會；②除對全局參數(shù)的約定外，密鑰交換不需要事先存在的基礎(chǔ)設(shè)施兩個缺點：①沒有提供雙方身份的任何信息，因此易受中間人攻擊；②算法是計算密集型的，容易遭受阻塞性攻擊密鑰確定協(xié)議IKE對Diffie-Hellman的改進：采用Cookie機制來防止擁塞攻擊；允許雙方協(xié)商得到一個組（group），相錄于Diffie-Hellman密鑰交換的全局參數(shù)；使用現(xiàn)時值來阻止重放攻擊；允許交換Diffie-Hellman的公鑰值；對Diffie-Hellman交換進行身份認證，以阻止中間人攻擊密鑰確定協(xié)議Cookie交換（Cookieexchange）要求各方在初始消息中發(fā)送一個偽隨機數(shù)Cookie，并要求對方確認。此確認必須在Diffie-Hellman密鑰交換的第一條消息中重復(fù)。如果源地址被偽造，則攻擊者就不會收到應(yīng)答。這樣，攻擊者僅能讓用戶產(chǎn)生應(yīng)答而不會進行Diffie-Hellman計算Cookie機制ISAKMP規(guī)定Cookie的產(chǎn)生必須滿足：Cookie必須依賴于特定的通信方，從而防止攻擊者得到一個正在使用真正的IP地址和UDP端口的Cookie時，也無法用該Cookie向目標(biāo)主機發(fā)送大量的來自隨機選取的IP地址和端口號的請求來浪費目標(biāo)主機的資源Cookie機制ISAKMP規(guī)定Cookie的產(chǎn)生必須滿足：除了發(fā)起實體以外的任何實體都不可能產(chǎn)生被它承認的Cookie。這就意味著發(fā)起實體在產(chǎn)生和驗證Cookie時，要使用本地的秘密信息，而且根據(jù)任何特定的Cookie都不可能推斷出該秘密信息Cookie機制ISAKMP規(guī)定Cookie的產(chǎn)生必須滿足：Cookie的產(chǎn)生和驗證必須盡可能地快速完成，從而阻止企圖通過占用處理器資源的阻塞攻擊一種產(chǎn)生Cookie的方法是對以下信息進行HASH運算后，取前64位：

源IP地址+目的IP地址+UDP源端口+UDP目的端口+

隨機數(shù)+當(dāng)前日期+當(dāng)前時間Cookie機制使用不同的組（group）進行Diffie-Hellman密鑰交換。每個組包含兩個全局參數(shù)的定義和算法標(biāo)識。當(dāng)前的規(guī)范包括如下幾個組：GroupIKE使用現(xiàn)時值（nonce）來反重放攻擊。每個現(xiàn)時值是本地產(chǎn)生的偽隨機數(shù)，在應(yīng)答中出現(xiàn)，并在交換時被加密以保護它的可用性防重放攻擊IKE使用三種不同的身份認證方法：數(shù)字簽名：用雙方均可以得到的散列值進行簽名來進行身份認證，每一方都用自己的私鑰加密散列值。散列值使用重要的身份參數(shù)（如用戶ID、現(xiàn)時值）來生成。公鑰加密：利用對方公鑰對用戶身份參數(shù)（如用戶ID、現(xiàn)時值）加密來進行身份認證。對稱密鑰加密：通過帶外機制得到密鑰，并且該密鑰對交換的身份參數(shù)進行加密。身份認證IKEv1密鑰交換過程密鑰交換過程發(fā)送IKE安全提議接受提議發(fā)送密鑰生成信息生成密鑰發(fā)送身份和驗證數(shù)據(jù)身份驗證和交換過程驗證查找匹配的提議發(fā)送確認的IKE安全提議生成密鑰發(fā)送密鑰生成消息身份驗證和交換過程驗證發(fā)送身份和驗證數(shù)據(jù)協(xié)商發(fā)起方協(xié)商響應(yīng)方①②③④⑤⑥發(fā)送IKE安全提議、密鑰生成和身份信息查找匹配的提議算法，生成密鑰和身份驗證協(xié)商發(fā)起方協(xié)商響應(yīng)方①接受提議和生成密鑰發(fā)送密鑰生成信息、身份信息和驗證數(shù)據(jù)②發(fā)送驗證數(shù)據(jù)交換過程驗證③（a）主模式（b）積極模式IKEv2密鑰交換過程密鑰交換過程密鑰交換過程發(fā)送IKE安全提議接受參數(shù)發(fā)送身份信息身份驗證和交換過程驗證查找匹配的提議發(fā)送確認的IKE安全參數(shù)身份驗證和交換過程驗證發(fā)送身份信息協(xié)商發(fā)起方協(xié)商響應(yīng)方①②③④發(fā)送控制信息根據(jù)控制信息進行相應(yīng)操作協(xié)商發(fā)起方協(xié)商響應(yīng)方①接受信息回應(yīng)控制信息②（a）初始交換過程（b）信息交換過程IKE協(xié)議定義了建立、協(xié)商、修改和刪除安全關(guān)聯(lián)的過程和報文格式。IKE報文由首部和一個或多個載荷組成，并包含在傳輸協(xié)議（規(guī)范要求在實現(xiàn)時必須支持UDP協(xié)議）IKE消息格式IKE消息格式

發(fā)起方SPI

應(yīng)答方SPI

071531消息ID鄰接載荷主版本次版本交換類型標(biāo)記23長度

07

81531鄰接載荷C保留載荷長度(a)

IKE首部(b)一般載荷首部載荷類型IKE消息格式載荷類型IKE消息格式IPsecv3和IKEv3協(xié)議依賴于多種密碼算法。每種應(yīng)用可能需要使用多種密碼算法，而每種密碼算法也有很多參數(shù)。為了提高互操作性，IETF通過RFC4308和RFC4869定義了各種應(yīng)用的推薦密碼算法和參數(shù)IKE密碼組件RFC4308IKE密碼組件RFC4869IKE密碼組件同RFC4308一樣，使用的密鑰算法包括：加密：對于ESP，認證加密使用128位或256位的AES密碼的GCM模式；對于IKE加密，與VPN密碼組一樣，使用密碼分組鏈（CBC）模式；消息認證：對于ESP，如果只認證，則用GMAC；對于IKE，消息認證由使用SHA-3的HMAC來提供。偽隨機數(shù)：同VPN密碼組一樣，IKEv2通過對重復(fù)使用消息認證的MAC來產(chǎn)生偽隨機數(shù)。IKE密碼組件對于Diffie-Hellman算法，規(guī)定使用橢圓曲線群上對素數(shù)求模。對于認證，也使用了橢圓曲線上的數(shù)字簽名。早期的IKEv2文檔使用的是基于RSA的數(shù)字簽名。與RSA相比，使用ECC可以用更短的密鑰就能達到相當(dāng)或更高的安全強度IKE密碼組件IKE交互過程抓包分析主模式第1條報文（6->4）IKE交互過程抓包分析主模式第2條報文（4->6）IKE交互過程抓包分析主模式的第3條報文（6->4）：密鑰交換（KeyExchange）IKE交互過程抓包分析主模式第4條報文（4->6）IKE交互過程抓包分析主模式的第5條報文（6->4）IKE交互過程抓包分析主模式第6條報文（4->6）IKE交互過程抓包分析快速模式第1條報文（6->4）IKE交互過程抓包分析快速模式第2條報文（4->6）IKE交互過程抓包分析快速模式第3條報文（6->4）IKE交互過程抓包分析快速模式第4條報文（4->6）IKE交互過程抓包分析六、SA組合為什么要組合SA？單個SA只能實現(xiàn)AH協(xié)議或ESP協(xié)議，而不能同時實現(xiàn)這兩者。但在實際應(yīng)用中，一些流量需要同時調(diào)用由AH和ESP提供的服務(wù)，某些流量可能需要主機間的IPsec服務(wù)的同時還需要在安全網(wǎng)關(guān)（如防火墻）間得到IPsec提供的服務(wù)。在這些情況下，同一個流量可能需要多個SA才能獲得想要的IPsec服務(wù)SA組合提供特定IPsec服務(wù)集而組合在一起的SA系列稱為“安全關(guān)聯(lián)束（SecurityAssociationBundle）”安全關(guān)聯(lián)束中的SA可以在不同節(jié)點上終止，也可在同一個節(jié)點上終止兩種方式將多個SA組合成安全關(guān)聯(lián)束：傳輸鄰接（transportadjacency）與隧道迭代（IteratedTunneling）SA組合在組合多個SA形成安全關(guān)聯(lián)束時，需要考慮認證和加密的順序問題先加密后認證先認證后加密SA組合SA組合SA組合SA組合SA組合SA組合七、IPsec的應(yīng)用IPsec在IP層對所有流量進行加密和/或認證，因此能夠保護各種基于IP的應(yīng)用終端用戶通過互聯(lián)網(wǎng)實現(xiàn)安全的遠程訪問分支機構(gòu)通過互聯(lián)網(wǎng)構(gòu)建一個安全的虛擬專用網(wǎng)絡(luò)與合作者建立企業(yè)間聯(lián)網(wǎng)和企業(yè)內(nèi)聯(lián)網(wǎng)接入將IPsec應(yīng)用于上述場景的實質(zhì)就是構(gòu)建基于IPsec的虛擬專用網(wǎng)（VirtualPrivateNetwork,VPN）IPsec的應(yīng)用VPN定義及分類VPNIPsec安全接入場景：網(wǎng)關(guān)到網(wǎng)關(guān)IPsec的應(yīng)用IPsec安全接入場景：網(wǎng)關(guān)到網(wǎng)關(guān)IPsec的應(yīng)用IPsec安全接入場景：終端到網(wǎng)關(guān)IPsec的應(yīng)用IPsec安全接入場景：典型應(yīng)用邏輯圖IPsec的應(yīng)用IPsec安全接入場景：典型應(yīng)用一IPsec的應(yīng)用IPsec安全接入場景：典型應(yīng)用二IPsec的應(yīng)用IPsec安全接入場景：典型應(yīng)用三IPsec的應(yīng)用IPsec應(yīng)用IPsec的應(yīng)用IPsec的應(yīng)用利用IPsec實現(xiàn)安全通信有以下優(yōu)點：當(dāng)在路由器或防火墻等邊界設(shè)備中啟用IPsec時，認證和加密過程均在路由器或防火墻中進行，而其后面的公司或者工作組內(nèi)部的通信不會引起與安全相關(guān)的開銷IPsec位于傳輸層之下，所以對應(yīng)用是透明的IPsec對終端用戶是透明的若有必要，IPsec給個人用戶提供安全性IPsec的應(yīng)用內(nèi)容提綱IPsec2

IPv6協(xié)議及其安全性分析3路由安全4

IPv4協(xié)議及其安全性分析1IPv6IPv6從IPv4向IPv6過渡采用逐步演進的方法，IETF推薦的過渡方案主要有：雙協(xié)議棧(dualstack)隧道(tunneling)網(wǎng)絡(luò)地址轉(zhuǎn)換IPv6IPv6部署情況（APNIC，2019.6）：IPv6IPv6通過IPsec來保證IP層的傳輸安全，提高了網(wǎng)絡(luò)傳輸?shù)谋Ｃ苄浴⑼暾?、可控性和抗否認性IPv6安全安全問題IPv4向IPv6過渡技術(shù)的安全風(fēng)險無狀態(tài)地址自動配置的安全風(fēng)險IPv6中PKI管理系統(tǒng)的安全風(fēng)險IPv6編址機制的隱患IPv6安全安全問題IPv6的安全機制對網(wǎng)絡(luò)安全體系的挑戰(zhàn)所帶來的安全風(fēng)險：正在服役的IDS/IPS/WAF不一定支持，于是可以暢行無阻IPv6安全IPv6安全內(nèi)容提綱IPsec2

IPv6協(xié)議及其安全性分析3路由安全4

IPv4協(xié)議及其安全性分析1路由協(xié)議R1H1H2內(nèi)部網(wǎng)關(guān)協(xié)議IGP（例如，RIP）自治系統(tǒng)A自治系統(tǒng)B自治系統(tǒng)CIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPIGPEGPEGPEGP內(nèi)部網(wǎng)關(guān)協(xié)議IGP（例如，OSPF）外部網(wǎng)關(guān)協(xié)議EGP（例如，BGP-4）IGPR3R2路由協(xié)議的脆弱性：協(xié)議設(shè)計上的問題，即協(xié)議機制上的不完善（如認證機制、防環(huán)路機制、路由度量機制等）導(dǎo)致的安全問題協(xié)議實現(xiàn)上的問題，即許多協(xié)議規(guī)范中的協(xié)議行為在實際網(wǎng)絡(luò)環(huán)境中并沒有實現(xiàn)或做的不夠完善而導(dǎo)致的安全問題管理配置產(chǎn)生的安全問題，很多網(wǎng)絡(luò)管理員在配置路由協(xié)議器時，沒有或錯誤地配置相應(yīng)的加密和認證機制，帶來了很多安全風(fēng)險路由協(xié)議BadNeighboronFreeBSD-FreeBSDIPv6協(xié)議棧路由協(xié)議相關(guān)4個漏洞分析IPv6路由協(xié)議棧實現(xiàn)安全路由協(xié)議的安全保障：IPv4網(wǎng)絡(luò)中，路由安全主要依靠路由協(xié)議本身提供的安全機制來保障，如認證和加密機制。而在IPv6網(wǎng)絡(luò)中，路由安全則主要依靠前面介紹的IPsec協(xié)議提供的認證和加密服務(wù)來保障路由協(xié)議一、RIP協(xié)議及其安全性分析RIP一種內(nèi)部網(wǎng)關(guān)協(xié)議分布式的基于距離向量的路由選擇三個版本：RIPv1（RFC1058）、RIPv2（RFC1723）和RIPng。RIPv2新增了變長子網(wǎng)掩碼的功能，支持無類域間路由、支持組播、支持認證功能，同時對RIP路由器具有后向兼容性。RIPng主要用于IPv6網(wǎng)絡(luò)RIP協(xié)議路由策略和哪些路由器交換信息？僅和相鄰路由器交換信息交換什么信息？當(dāng)前本路由器所知道的全部信息，即自己的路由表在什么時候交換信息？按固定的時間間隔交換路由信息RIP協(xié)議協(xié)議報文兩類報文：更新報文和請求報文。更新報文用于路由表的分發(fā)，請求報文用于路由器發(fā)現(xiàn)網(wǎng)上其它運行RIP協(xié)議的路由器。RIP協(xié)議報文使用UDP協(xié)議進行傳送RIP協(xié)議RIPv1不支持認證，且使用不可靠的UDP協(xié)議作為傳輸協(xié)議，安全性較差。如果在沒有認證保護的情況下，攻擊者可以輕易偽造RIP路由更新信息，并向鄰居路由器發(fā)送，偽造內(nèi)容為目的網(wǎng)絡(luò)地址、子網(wǎng)掩碼地址與下一條地址，經(jīng)過若干輪的路由更新，網(wǎng)絡(luò)通信將面臨癱瘓的風(fēng)險RIP協(xié)議安全RIPv2在其報文格式中增加了一個可以設(shè)置16個字符的認證選項字段，支持明文認證和MD5加密認證兩種認證方式，字段值分別是16個字符的明文密碼字符串或者MD5簽名。RIP認證以單向為主，R2發(fā)送出的路由被R1授受，反之無法接受。另外，RIPv2協(xié)議路由更新需要配置統(tǒng)一的密碼明文認證的安全性仍然較弱RIP協(xié)議安全對于不安全的RIP協(xié)議，中小型網(wǎng)絡(luò)通常可采取的防范措施包括：①將路由器的某些接口配置為被動接口，配置為被動接口后，該接口停止向它所在的網(wǎng)絡(luò)廣播路由更新報文，但是允許它接收來自其他路由器的更新報文；②配置路由器的訪問控制列表，只允許某些源IP地址的路由更新報文進入列表RIP協(xié)議安全RIPng為IPv6環(huán)境下運行的RIP協(xié)議，采用和RIPv2完全不同的安全機制。RIPng使用和RIPv1相似的報文格式，充分利用IPv6中IPsec提供的安全機制，包括AH認證、ESP加密以及偽報頭校驗等，保證了RIPng路由協(xié)議交換路由信息的安全。RIP協(xié)議安全二、OSPF協(xié)議及其安全性分析路由策略和哪些路由器交換信息？向本自治系統(tǒng)中所有路由器發(fā)送信息，通常洪泛法交換什么信息？與本路由器相鄰的所有路由器的鏈路狀態(tài)，只是路由器所知部分信息表在什么時候交換信息？當(dāng)鏈路狀態(tài)發(fā)生變化時，路由器向所有路由器發(fā)送此信息；定期同步鏈路狀態(tài)OSPF協(xié)議OSPF使用分布式鏈路狀態(tài)協(xié)議(linkstateprotocol)由于OSPF依靠各路由器之間頻繁地交換鏈路狀態(tài)信息，因此所有的路由器都能建立一個鏈路狀態(tài)數(shù)據(jù)庫（LinkStateDatabase,LSDB），這個數(shù)據(jù)庫實際上就是全網(wǎng)拓撲結(jié)構(gòu)圖每一個路由器使用LSDB中的數(shù)據(jù)，構(gòu)造自己的路由表（例如，使用Dijkstra算法）OSPF協(xié)議OSPF協(xié)議報文類型1，問候(Hello)報文，用來發(fā)現(xiàn)和維持鄰站的可達性類型2，數(shù)據(jù)庫描述(DatabaseDescription)報文，向鄰站給出自己的鏈路狀態(tài)數(shù)據(jù)庫中的所有鏈路狀態(tài)項目的摘要信息類型3，鏈路狀態(tài)請求(LinkStateRequest,LSR)報文，向?qū)Ψ秸埱蟀l(fā)送某些鏈路狀態(tài)項目的詳細信息OSPF協(xié)議OSPF協(xié)議報文類型4，鏈路狀態(tài)更新(LinkStateUpdate,LSU)報文，用洪泛法向全網(wǎng)發(fā)送更新的鏈路狀態(tài)類型5，鏈路狀態(tài)確認(LinkStateAcknowledgment,LSAck)報文，對鏈路更新報文的確認OSPF協(xié)議OSPF不用UDP而是直接用IP數(shù)據(jù)報傳送（其IP數(shù)據(jù)報首部的協(xié)議字段值為89）其報文OSPF協(xié)議OSPF協(xié)議可以對接口、區(qū)域、虛鏈路進行認證接口認證要求在兩個路由器之間必須配置相同的認證口令。區(qū)域認證是指所有屬于該區(qū)域的接口都要啟用認證，因為OSPF以接口作為區(qū)域分界。區(qū)域認證接口與鄰接路由器建立鄰居需要有相同的認證方式與口令，但在同一區(qū)域中不同網(wǎng)絡(luò)類型可以有不同的認證方式和認證口令。配置區(qū)域認證的接口可以與配置接口認證的接口互相認證，使用MD5認證口令I(lǐng)D要相同OSPF安全OSPF認證方式空認證（NULL，即不認證，類型為0），默認認證方式簡單口令認證（類型為1）MD5加密身份認證（類型為2）OSPF報文格式中有二個與認證有關(guān)的字段：認證類型（AuType,16位）、認證數(shù)據(jù)（Authentication,64位）OSPF安全同RIPng一樣，OSPFv3協(xié)議自身不再有加密認證機制，取而代之的是通過IPv6的IPsec協(xié)議來保證安全性，路由協(xié)議必須運行在支持IPsec的路由器上。IPsec可確保路由器報文來自于授權(quán)的路由器；重定向報文來自于被發(fā)送給初始包的路由器；路由更新未被偽造OSPF安全OSPF攻擊方式最大年齡（MaxAgeattack）攻擊序列號加1（Sequence++）攻擊最大序列號攻擊重放攻擊篡改攻擊OSPF安全三、BGP協(xié)議及其安全性分析BGP協(xié)議是一種應(yīng)用于AS之間的邊界路由協(xié)議，而且運行邊界網(wǎng)關(guān)協(xié)議的路由器一般都是網(wǎng)絡(luò)上的骨干路由器運行BGP協(xié)議的路由器相互之間需要建立TCP連接以交換路由信息，這種連接稱為BGP會話(Session)BGP協(xié)議BGP定義了四種主要報文，即：打開(Open)報文，用來與相鄰的另一個BGP發(fā)言人建立關(guān)系更新(Update)報文，用來發(fā)送某一路由的信息以及列出要撤消的多條路由?；?KeepAlive)報文，用來確認打開報文和周期性地證實鄰站關(guān)系通知(Notification)報文，用來發(fā)送檢測到的差錯BGP協(xié)議BGP協(xié)議BGP發(fā)言人BGP發(fā)言人BGP發(fā)言人BGP發(fā)言人BGP發(fā)言人AS1AS3AS2AS5AS4BGP協(xié)議BGP協(xié)議最主要的安全問題在于缺乏一個安全可信的路由認證機制，即BGP無法對所傳播的路由信息的安全性進行驗證。每個自治系統(tǒng)向外通告自己所擁有的CIDR地址塊，并且協(xié)議無條件信任對等系統(tǒng)的路由通告，這將就導(dǎo)致一個自治系統(tǒng)向外通告不屬于自己的前綴時，也會被BGP用戶認為合法，從而接受和傳播，導(dǎo)致路由攻擊的發(fā)生BGP安全由于BGP協(xié)議使用TCP作為其傳輸協(xié)議，因此同樣會面臨很多因為使用TCP而導(dǎo)致的安全問題，如SYNFlood攻擊、序列號預(yù)測等BGP安全BGP協(xié)議的路由更新機制也存在被攻擊的威脅。2011年美國明尼蘇達大學(xué)M.Schuchard等人在NDSS2011國際會議上提出了一種基于BGP協(xié)議漏洞的CXPST（CoordinatedCrossPlaneSessionTermination）攻擊方法，俗稱“數(shù)字大炮”BGP安全：數(shù)字大炮數(shù)字大炮BGP安全：數(shù)字大炮ABR1R2關(guān)鍵路徑關(guān)鍵路徑BGP協(xié)議數(shù)字大炮BGP安全：數(shù)字大炮BGP系統(tǒng)是一個信譽系統(tǒng)，它幾乎完全依賴自治系統(tǒng)（運營商）之間的信任與協(xié)作如果某個運營商有意或無意地把不屬于自己地址范圍的路由信息（路由前綴）宣告給網(wǎng)絡(luò)鄰居（這種現(xiàn)象被稱為路由劫持或路由泄露），那么鄰居的網(wǎng)絡(luò)可能把去往該網(wǎng)絡(luò)的數(shù)據(jù)包全部轉(zhuǎn)發(fā)給這個搗亂的運營商，從而導(dǎo)致路由劫持攻擊BGP安全：路由劫持BGP劫持BGP安全：路由劫持/articles/5042BGP安全：路由劫持BGP安全：路由劫持BGP安全：路由劫持BGP安全：路由劫持盡管正在研究的路由安全機制（如RPKI、BGPSec等）可以在防范這種路由劫持或路由泄露攻擊，但是這些技術(shù)離大規(guī)模部署還有很長的路要走。短期內(nèi)，我們?nèi)匀贿€只能相信運營商大部分都是誠實的，不會故意濫用別人的信任。BGP安全：路由劫持2018年9月，NIST與DHS團隊共同發(fā)布了其BGP路由來源驗證（ROV）標(biāo)準(zhǔn)的初稿，此項標(biāo)準(zhǔn)將幫助互聯(lián)網(wǎng)服務(wù)供應(yīng)商與云服務(wù)供應(yīng)商抵御BGP劫持攻擊IETF網(wǎng)站上還以RFC8210與RFC8206的形式發(fā)布了BGPRPKI與BGPsec兩項SIDR協(xié)議標(biāo)準(zhǔn)BGP安全RPKIBGP安全BGPSECBGP安全國際政治對BGP安全的影響（2022俄烏戰(zhàn)爭）BGP安全本章小結(jié)作業(yè)第七章傳輸層安全內(nèi)容提綱SSL2TLS3SSL/TLSVPN4傳輸層安全問題1傳輸層安全為保證網(wǎng)絡(luò)應(yīng)用間，特別是應(yīng)用廣泛的Web應(yīng)用數(shù)據(jù)傳輸?shù)陌踩裕C密性、完整性和真實性），可以在多個網(wǎng)絡(luò)層次上采取安全措施。

IP/IPSec

TCP

HTTPFTPSMTP

IP

TCP

HTTPFTPSMTP

IP

UDP

SSLorTLS

TCP

Kerberos

SMTP

HTTP

S/MIME

(a)網(wǎng)絡(luò)層(b)傳輸層(c)應(yīng)用層UDP協(xié)議源端口目的端口長度檢驗和數(shù)據(jù)數(shù)據(jù)首部首部UDP用戶數(shù)據(jù)報IP數(shù)據(jù)報2222字節(jié)發(fā)送在前UDP協(xié)議可用于風(fēng)暴型DDoS。由于UDP協(xié)議不需要與目標(biāo)建立連接，因此攻擊者很容易通過偽造源地址的方式向目標(biāo)發(fā)送攻擊報文，非常簡單易行攻擊者利用控制的僵尸網(wǎng)絡(luò)中的大量主機向攻擊目標(biāo)（主機或網(wǎng)絡(luò)設(shè)備）發(fā)送大量的UDP數(shù)據(jù)包，使其忙于處理和回應(yīng)UDP報文，導(dǎo)致目標(biāo)設(shè)備不能提供正常服務(wù)或者直接死機，嚴重的會造成全網(wǎng)癱瘓。UDP協(xié)議TCP協(xié)議TCP協(xié)議TCP協(xié)議安全性分析網(wǎng)絡(luò)掃描拒絕服務(wù)（DoS）攻擊TCP會話劫持攻擊TCP協(xié)議端口掃描TCP協(xié)議端口掃描：TCPConnect掃描TCPSYN掃描TCPFIN掃描Xmas掃描和Null掃描TCP協(xié)議DDoS攻擊：TCPSYNFloodingTCP協(xié)議連接劫持：TCP協(xié)議只要TCP包中的源端口、目的端口、Seq、Ack正確，即可被正確接收。當(dāng)?shù)玫饺肭终邩?gòu)造的TCP數(shù)據(jù)包，協(xié)議會假設(shè)數(shù)據(jù)包是來源于TCP連接中另一方的合法數(shù)據(jù)包，并且發(fā)送響應(yīng)包到（入侵者構(gòu)造的數(shù)據(jù)包中設(shè)置的IP地址）。隨后，原來的TCP連接會由于計數(shù)器不匹配而斷開連接。連接劫持：TCP協(xié)議關(guān)鍵：猜測Seq、Ack，如果是旁路劫持還需猜測源端口號連接劫持：TCP協(xié)議內(nèi)容提綱SSL2TLS3SSL/TLSVPN4傳輸層安全問題1由于Web應(yīng)用協(xié)議主要通過傳輸層的TCP協(xié)議來傳輸其協(xié)議報文，而TCP協(xié)議不支持加密和認證，因此并不能保證Web應(yīng)用傳輸上的安全網(wǎng)景公司（Netscape）于1994年開發(fā)了安全套接字（SecuritySocketLayer,SSL）協(xié)議SSL版本：2.0(1995年)、3.0(1996年，2011年RFC6101)Web安全需求Web安全需求SSL利用TCP協(xié)議為上層應(yīng)用提供端到端的安全傳輸服務(wù)，包括認證和加密SSL體系結(jié)構(gòu)

IP

TCP

SSL握手協(xié)議

SSL記錄協(xié)議SSL密碼變更規(guī)格協(xié)議SSL告警協(xié)議HTTP協(xié)議SSL體系結(jié)構(gòu)SSL幾個協(xié)議之間的關(guān)系是：使用握手協(xié)議協(xié)商加密和MAC算法以及保密密鑰，進行身份認證使用密碼變更規(guī)格協(xié)議變更連接上使用的密碼機制使用記錄協(xié)議對交換的數(shù)據(jù)進行加密和完整性檢查使用告警協(xié)議定義數(shù)據(jù)傳輸過程中出現(xiàn)的問題并通知相關(guān)方SSL體系結(jié)構(gòu)SSL兩個重要概念連接（connection）：是指一種能夠提供合適服務(wù)類型的傳輸通道。對SSL來說，這種連接是點對點、暫時的。每條連接都與一個會話關(guān)聯(lián)會話（session）：是指客戶與服務(wù)器之間的一種關(guān)聯(lián)，由握手協(xié)議創(chuàng)建，定義了一組多個連接共享的密碼安全參數(shù)。定義會話的目的主要是避免為每次建立連接而進行復(fù)雜的密碼參數(shù)協(xié)商過程SSL體系結(jié)構(gòu)SSL兩個重要概念任何一對通信實體（如客戶和服務(wù)器上的HTTP應(yīng)用）之間可以有多條安全連接，理論上也允許一對實體之間同時有多個會話，實際上很少出現(xiàn)每個會話有多種狀態(tài)一旦會話建立，就進入當(dāng)前操作（發(fā)送和接收）狀態(tài)。在握手協(xié)議執(zhí)行期間，會進入讀（接收）掛起狀態(tài)和寫（發(fā)送）掛起狀態(tài)。握手完成，掛起狀態(tài)又回到當(dāng)前操作狀態(tài)SSL體系結(jié)構(gòu)SSL連接狀態(tài)參數(shù)SSL體系結(jié)構(gòu)SSL會話狀態(tài)參數(shù)SSL體系結(jié)構(gòu)SSL保障的安全屬性：機密性：SSL客戶機和服務(wù)器之間傳送加密數(shù)據(jù)。完整性：SSL可避免服務(wù)器和客戶機之間的信息被破壞。認證性：SSL握手時要求交換證書，通過驗證證書來保證對方身份的合法性（服務(wù)器認證+可選的客戶端認證）。SSL實現(xiàn)的安全服務(wù)一、SSL記錄協(xié)議記錄協(xié)議在SSL握手協(xié)議完成客戶端和服務(wù)器之間的握手過程后使用，即客戶端和服務(wù)器完成雙方的身份鑒別并確定安全信息交換使用的算法后執(zhí)行保密性：使用握手協(xié)議得到的傳統(tǒng)加密共享密鑰來加密SSL載荷來實現(xiàn)保密性完整性：使用握手協(xié)議得到的MAC共享密鑰對SSL載荷進行消息完整性檢驗SSL記錄協(xié)議報文格式（示例載荷為上層應(yīng)用協(xié)議報文）SSL記錄協(xié)議明文（壓縮可選）內(nèi)容類型MAC（0,

16或20字節(jié)）主版本次版本壓縮后的長度加密SSL記錄協(xié)議ProtocolTypeProtocolVersionLengthMessageTypeLengthProtocolVersionRandom0135691143ByteOffset記錄協(xié)議首部載荷協(xié)議報文(示例為握手協(xié)議報文)20：密碼變更規(guī)格協(xié)議21：告警協(xié)議22：握手協(xié)議23：上層應(yīng)用協(xié)議（HTTP）報文格式（載荷為上層協(xié)議報文）SSL記錄協(xié)議記錄協(xié)議對應(yīng)用數(shù)據(jù)的處理過程SSL記錄協(xié)議

應(yīng)用數(shù)據(jù)分段壓縮添加MAC加密添加SSL首部1、如何得知采用的加密算法、MAC算法、壓縮算法？2、如何得到對稱加密密鑰？記錄協(xié)議支持的加密算法SSL記錄協(xié)議SSL采用的是鏈?zhǔn)郊用埽〝?shù)字信封）方法：采用對稱加密算法加密消息（SSL記錄協(xié)議），用公開密碼算法交換對稱加密算法的對稱密鑰（SSL握手協(xié)議）SSL記錄協(xié)議二、SSL密碼變更規(guī)格協(xié)議協(xié)議由一個僅包含1字節(jié)且值為1的消息組成，使得連接從掛起狀態(tài)改變到當(dāng)前狀態(tài)，用于更新此連接使用的密碼組密碼變更規(guī)格協(xié)議1(a)密碼更改規(guī)范協(xié)議報文格式1

B一旦握手商定了一組新的密鑰，都會發(fā)送一條變更規(guī)格協(xié)議報文指示啟用新的密鑰問題：為什么不作為其它協(xié)議（如握手協(xié)議）的一條報文而要獨立成一個協(xié)議？密碼變更規(guī)格協(xié)議三、Alert協(xié)議當(dāng)客戶端和服務(wù)器發(fā)現(xiàn)錯誤時，需要通過告警協(xié)議向?qū)Ψ桨l(fā)送一個告警消息同應(yīng)用數(shù)據(jù)一樣，SSL告警協(xié)議報文同樣交由SSL記錄協(xié)議進行壓縮和加密處理后發(fā)送告警協(xié)議協(xié)議格式：第1個字節(jié)表示告警類型：值1表示告警，值2表示致命錯誤。如果是致命錯誤，則SSL立即關(guān)閉SSL連接，而會話中的其它連接將繼續(xù)進行，但不會再在此會話中建立新連接第2個字節(jié)包含指定告警信息的代碼告警協(xié)議類型(b)告警協(xié)議報文格式1

B告警1

B告警協(xié)議四、握手協(xié)議SSL握手協(xié)議是客戶端和服務(wù)器用SSL連接通信時使用的第一個子協(xié)議，在開始傳輸上層應(yīng)用數(shù)據(jù)之前使用。該協(xié)議允許服務(wù)器和客戶端相互驗證，協(xié)商加密和MAC算法以及加密密鑰，用來保護在SSL記錄協(xié)議中發(fā)送的數(shù)據(jù)握手協(xié)議協(xié)議格式握手協(xié)議類型長度內(nèi)容1

B3

B≥0

B(c)握手協(xié)議報文格式協(xié)議格式握手協(xié)議客戶端與服務(wù)器之間建立邏輯連接的初始交換過程包括四個階段握手協(xié)議握手協(xié)議不需要CA實時參與，也不需要實時查詢證書庫密碼套件（CipherSuite）：SSL/TLS握手期間協(xié)商安全設(shè)置的算法（密鑰交換算法、認證算法、加密算法及密鑰長度、校驗算法）的組合握手協(xié)議為了更好理解SSL協(xié)議的握手過程，結(jié)合實例，使用Wireshark抓包分析SSL握手過程中客戶端與服務(wù)器間的交互過程。下面以訪問為例，使用Wireshark抓包分析SSL握手過程中客戶端與服務(wù)器間的交互過程。本例中服務(wù)器/（72），客戶端為本機瀏覽器（2）。例中協(xié)議版本為TLS1.2，過程與SSL類似。握手協(xié)議ClientHello消息握手協(xié)議：階段1TLS第1次握手TLS第2次握手TLS第3次握手TLS第4次握手ClientHello消息握手協(xié)議：階段1TLS版本端戶端隨機數(shù)密碼套件列表ServerHello消息握手協(xié)議：階段1服務(wù)器隨機數(shù)服務(wù)器選擇的密碼套件服務(wù)器確認的TLS版本Certificate消息握手協(xié)議：階段2服務(wù)器證書Certificate消息握手協(xié)議：階段2Certificate消息握手協(xié)議：階段2Certificate消息握手協(xié)議：階段2服務(wù)器發(fā)送完Certificate消息后繼續(xù)發(fā)送ServerKeyExchange和ServerHelloDone消息，ServerKeyExchange消息中包含有密鑰交換算法所需要的額外參數(shù)。ServerHelloDone消息表示服務(wù)器已發(fā)送完此階段的全部信息握手協(xié)議：階段3與4橢圓曲線公鑰簽名算法服務(wù)器端橢圓曲線公鑰客戶端發(fā)送ClientKeyExchange和ChangeCipherSpec消息握手協(xié)議：階段3與4這里有客戶器端橢圓曲線公鑰接著服務(wù)器同樣發(fā)送ChangeCipherSpec消息通知服務(wù)器到客戶端的握手過程結(jié)束，并發(fā)送一個加密的握手消息EncryptedHandshakeMessage握手協(xié)議：階段3與4之后，服務(wù)端也會使用SessionSecret加密一段Finished消息發(fā)送給客戶端，以驗證之前通過握手建立起來的加密通道是否成功。根據(jù)之前的握手信息，如果客戶端和服務(wù)端都能對Finished信息進行正常加解密且消息正確的被驗證，則說明握手通道已經(jīng)建立成功，接下來，雙方可以使用上面產(chǎn)生的SessionSecret對數(shù)據(jù)進行加密傳輸了。握手協(xié)議：階段3與4五、密鑰生成采用非對稱密碼算法進行身份鑒別（認證）和密鑰交換，身份鑒別通過后協(xié)商預(yù)（備）主密鑰，雙方各自計算主密鑰，進而推導(dǎo)出工作密鑰（會話密鑰）。使用工作密鑰進行數(shù)據(jù)加解密和完整性檢驗密鑰種類服務(wù)端密鑰：為非對稱密碼算法的密鑰對，包括簽名密鑰對（用于握手過程中服務(wù)端身份鑒別）和加密密鑰對（用于預(yù)主密鑰的協(xié)商）客戶端密鑰：為非對稱密碼算法的密鑰對，包括簽名密鑰對（用于握手過程中服務(wù)端身份鑒別）和加密密鑰對（用于預(yù)主密鑰的協(xié)商）預(yù)主密鑰（pre_master_secret,PM）：雙方協(xié)商生成的密鑰素材，用于生成主密鑰密鑰種類主密鑰（master_secret）：由預(yù)主密鑰（PM）、客戶端隨機數(shù)（CR）、服務(wù)端隨機數(shù)（SR）、常量字符串，經(jīng)計算生成的48字節(jié)密鑰素材，用于生成工作密鑰工作密鑰：包括數(shù)據(jù)加密密鑰（用于數(shù)據(jù)的加密和解密）和校驗密鑰（用于數(shù)據(jù)的完整性計算和校驗）。發(fā)送方用的工作密鑰稱為寫密鑰，接收方使用的工作密鑰稱為讀密鑰密鑰種類共享主密鑰是利用安全密鑰交換為此會話建立的一個一次性48字節(jié)的值，生成過程分兩步：第一步交換預(yù)主密鑰（握手協(xié)議的“階段3”）第二步雙方計算主密鑰。密鑰生成計算主密鑰‘A’PMCRSR‘BB’PMCRSR‘CCC’PMCRSRSHA-1SHA-1SHA-1PM散列PM散列PM散列MD5MD5MD5散列散列散列PM：預(yù)備主密鑰SR：服務(wù)器隨機數(shù)CR：客戶端隨機數(shù)主密鑰（48字節(jié)）計算主密鑰計算數(shù)據(jù)加密密鑰（會話密鑰）和校驗密鑰及相關(guān)參數(shù)計算工作密鑰‘A’MCRSR‘BB’MCRSR‘···’MCRSRSHA-1SHA-1SHA-1M散列M散列M散列MD5MD5MD5散列散列散列M：主密鑰SR：服務(wù)器隨機數(shù)CR：客戶端隨機數(shù)密鑰參數(shù)······六、SSL安全性分析SSL的安全性分析SSL協(xié)議的安全性隱患1）預(yù)主密鑰master_secretSSL會話密鑰2）能否保證隨機數(shù)質(zhì)量也是SSL的安全隱患。3）有可能遭受中間人攻擊。4）利用SSL的攻擊無法被IDS檢測和FW過濾到。5）Web服務(wù)器使用SSL時，吞吐量會顯著下降。6）不能保證Web瀏覽器和服務(wù)器自身安全。2024/7/22243增強SSL安全性

增強master_secret的保密性預(yù)主密鑰的口令加密方法和硬件加密方法。提高隨機數(shù)的質(zhì)量用硬件隨機數(shù)發(fā)生器產(chǎn)生的隨機數(shù)作為產(chǎn)生隨機數(shù)的軟件方法PRNG的種子，進行高強度處理。提高證書CA的可靠性在服務(wù)器認證階段，CA控制所有證書的頒發(fā)和有效性判斷。2024/7/22244內(nèi)容提綱SSL2TLS3SSL/TLSVPN4傳輸層安全問題1IETF在SSL3.0版本的基礎(chǔ)上制定了SSL的互聯(lián)網(wǎng)標(biāo)準(zhǔn)版本，稱為“傳輸層安全”(TransportLayerSecurity，TLS)，使SSL更安全、協(xié)議規(guī)范更精確和完善。2011年發(fā)布的RFC6167中建議禁用SSL2.0,2015年發(fā)布的RFC7568中建議禁用SSL3.0TLS版本：TLS1.0(RFC2246,1999)，TLS1.1(RFC4346,2006)，TLS1.2(RFC5246,2008)，TLS1.3(RFC8446,2018)。其中，TLS1.0對應(yīng)SSL的3.0版名稱：SSL,SSL/TLSTLS版本號TLS1.0的主版本為3,次版本為1，而與之對應(yīng)的SSL3.0的主版本為3，次版本為0。TLS1.1的主版本為3，次版本為2消息認證碼TLS的MAC與SSL3.0的MAC有兩點不同：TLS使用RFC2104中定義的HMAC算法；TLS使用稱為“PRF”的偽隨機函數(shù)TLS與SSL的差異告警碼除no_certificate外，TLS繼承了SSL3.0中定義的所有告警碼。另外，還定義了新的告警碼密碼套件TLS和SSL3.0存在細小差別，即TLS不支持Fortezza密鑰交換、加密算法，而SSL3.0是支持的TLS與SSL的差異客戶端證書類型在CertificateRequest消息中，TLS支持SSL3.0中定義的rsa_sign,dss_sign,rsa_fixed_dh和dss_fixed_dh證書，但不支持SSL3.0支持的rsa_ephemeral_dh,dss_ephemeral和fortezza_kea證書TLS與SSL的差異CertificateVerify消息TLS在CertificateVerify消息中計算MD5和SHA-1散列碼時，計算的輸入與SSL3.0有少許差別，但安全性相當(dāng)僅對handshake_message進行MD5或SHA-1散列值計算，而在SSL3.0中散列值計算還包括主密鑰和填充，但這些額外信息似乎并沒有增加安全性TLS與SSL的差異Finished消息TLS在Finished消息中計算MD5和SHA-1散列碼時，計算的輸入與SSL3.0有少許差別，但安全性相當(dāng)TLS與SSL的差異密碼計算TLS和SSL3.0在計算主密鑰值（mastersecret）時采用的方式不同，過程如下：TLS與SSL的差異填充在SSL中，填充后的數(shù)據(jù)長度正好是分組加密算法中分組長度的最小整數(shù)倍。而TLS填充后的數(shù)據(jù)長度可以是分組長度的任意整數(shù)倍（但填充最大長度為255字節(jié)）。例如，如果明文（如果使用了壓縮算法則是壓縮后的明文）加MAC再加上表示填充長度的1個字節(jié)共79字節(jié)，則填充長度按字節(jié)計算時可以是1、9、17、25等，直到249。這種可變填充長度可以防止基于對報文長度進行分析的攻擊TLS與SSL的差異2018年8月，經(jīng)過28次草案后，IETF正式發(fā)布了TLS1.3版（RFC8446），這也是TLS演進史上最大的一次改變。改變主要集中在性能和安全性上TLS1.3首先是安全上的考慮TLS廣泛的應(yīng)用使得其成為了攻擊者的“眾矢之的”，這些攻擊或利用TLS設(shè)計本身存在的不足（如幸運十三攻擊、三次握手攻擊、跨協(xié)議攻擊等），或利用TLS所用密碼原語本身的缺陷（如RC4加密、RSA-PKCS#1v1.5加密等），或利用TLS實現(xiàn)庫中的漏洞（如心臟出血攻擊等）TLS1.3其次是性能上的考慮近年來，對網(wǎng)絡(luò)上所有通信使用加密傳輸已經(jīng)成為了主流趨勢，很多Web應(yīng)用都開始強制使用基于TLS的HTTPS，而不是采用明文傳輸?shù)腍TTP。這對保護我們在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)避免被竊聽和注入攻擊有積極影響，但是不足之處在于交互雙方必須運行復(fù)雜的TLS握手協(xié)議才能開始傳輸信息。TLS1.3禁止使用RSA密鑰交換算法“RSA密鑰交換”和瞬時Diffie-Hellman交換，這兩種模式都可以讓客戶端和服務(wù)器得到共享密鑰，但是RSA模式有一個嚴重的缺陷：它不滿足前向保密（forwardsecret），以及“百萬消息攻擊”等攻擊僅保留瞬時Diffie-Hellman作為唯一的秘鑰交換機制TLS1.3：密鑰交換密鑰交換TLS1.3：密鑰交換密鑰交換：TLS1.2vs.TLS1.3TLS1.3：密鑰交換密鑰交換：TLS1.2vs.TLS1.3TLS1.3：密鑰交換減少不安全的Diffie-Hellman參數(shù)選項選擇Diffie-Hellman參數(shù)時，提供太多的選項會導(dǎo)致選擇出錯誤的選項。TLS1.3：密鑰交換刪除不安全的認證加密方法CBC模式和填充之間的交互也是SSL3.0和一些TLS實現(xiàn)中出現(xiàn)的著名的POODLE漏洞的成因。TLS1.3中允許的唯一認證加密方法是AEAD（AuthenticatedEncryptionwithAdditionalData），它將機密性和完整性整合到一個無縫操作中TLS1.3：認證加密方法POODLE漏洞禁止一些安全性較弱的密碼原語TLS1.3已刪除所有可能存在問題的密碼組件和密碼模式，包括CBC模式密碼或不安全的流式密碼，如RC4。建議用SHA-2，不建議使用安全性較弱的MD5和SHA-1TLS1.3：刪除不安全的密碼套件對整個握手過程簽名在TLS1.2及更早版本中，服務(wù)器的簽名僅涵蓋部分握手協(xié)議報文，其它使用對稱MAC來確保握手未被篡改。這種疏忽導(dǎo)致了許多嚴重的安全漏洞，如FREAK、LogJam攻擊等。FREAK攻擊也稱為降級攻擊TLS1.3服務(wù)器對整個握手記錄進行簽名，包括密鑰協(xié)商，避免三次握手攻擊。此外，還實現(xiàn)了握手協(xié)議和記錄協(xié)議的密鑰分離。TLS1.3：全過程簽名對整個握手過程簽名TLS1.3：全過程簽名TLSv1.2對整個握手過程簽名TLS1.3：全過程簽名TLSv1.2TLSv1.3性能上的改進SSL：“2-RTT(RoundTripTime)”，200msTLS1.3舍棄了RSA的密鑰協(xié)商過程，然后基于ECDH密鑰協(xié)商算法（EC即橢圓曲線，DH是指“Diffie-Hellman”）優(yōu)化了整個過程，改為“1-RTT

”TLS1.3除了對新建連接過程進行優(yōu)化之外，對連接恢復(fù)過程也進行了優(yōu)化，做到了零次往返（0-RTT）TLS1.3：性能改進性能上的考慮：握手過程的改進TLS1.3：性能改進性能上的考慮：握手過程的改進TLS1.3：性能改進性能上的考慮：握手過程的改進TLS1.3：性能改進性能上的改進TLS1.3：性能改進TLS1.22-RTTTLS1.31-RTT查看目標(biāo)網(wǎng)站支持的TLS版本RFC8998：定義了兩個TLS1.3中的國密加密套件：SM2橢圓曲線ID，SM2-SM3的簽名?法TLS支持國密算法內(nèi)容提綱SSL2TLS3SSL/TLSVPN4傳輸層安全問題1IPsecVPN也有一些不足之處：無法實現(xiàn)基于用戶的授權(quán)可能泄露內(nèi)部網(wǎng)絡(luò)結(jié)構(gòu)利用基于SSL/TLS的V