計算機網(wǎng)絡(luò)安全原理（第2版）課件 第7章 傳輸層安全

第七章傳輸層安全內(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é)議不需要與目標建立連接，因此攻擊者很容易通過偽造源地址的方式向目標發(fā)送攻擊報文，非常簡單易行攻擊者利用控制的僵尸網(wǎng)絡(luò)中的大量主機向攻擊目標（主機或網(wǎng)絡(luò)設(shè)備）發(fā)送大量的UDP數(shù)據(jù)包，使其忙于處理和回應(yīng)UDP報文，導(dǎ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采用的是鏈式加密（數(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/2269增強SSL安全性

增強master_secret的保密性預(yù)主密鑰的口令加密方法和硬件加密方法。提高隨機數(shù)的質(zhì)量用硬件隨機數(shù)發(fā)生器產(chǎn)生的隨機數(shù)作為產(chǎn)生隨機數(shù)的軟件方法PRNG的種子，進行高強度處理。提高證書CA的可靠性在服務(wù)器認證階段，CA控制所有證書的頒發(fā)和有效性判斷。2024/7/2270內(nèi)容提綱SSL2TLS3SSL/TLSVPN4傳輸層安全問題1IETF在SSL3.0版本的基礎(chǔ)上制定了SSL的互聯(lián)網(wǎng)標準版本，稱為“傳輸層安全”(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查看目標網(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的VPN可以很好解決遠程終端訪問內(nèi)部網(wǎng)絡(luò)時存在的上述問題(SSL/TLSVPN簡稱為SSLVPN)SSL/TLSVPN實現(xiàn)過程SSL/TLSVPNSSL/TLSVPNWeb代理SSL/TLSVPNWeb代理SSL/TLSVPN端口映射SSL/TLSVPN端口映射SSL/TLSVPNIP連接SSL/TLSVPNIP連接SSL/TLSVPN與單純SSL/TLS只對某些TCP應(yīng)用（如HTTPS）進行保護相比，SSL/TLSVPN利用TCP以及SSL對TCP會話的保護，可實現(xiàn)對基于TCP的所有應(yīng)用的保護與IPsecVPN相比，SSL/TLSVPN可以提供更細粒度的訪問控制；使用方便，只需使用Web瀏覽器即可訪問；不會給遠程接入終端泄露內(nèi)部網(wǎng)絡(luò)拓撲；提供端到端的安全保護SSL/TLSVPN實際應(yīng)用中，IPsecVPN與SSLVPN的應(yīng)用場景是不一樣的。IPsecVPN是在網(wǎng)絡(luò)層實現(xiàn)加密通信，故IPsecVPN主要應(yīng)用于將遠程終端或分支機構(gòu)網(wǎng)絡(luò)與機構(gòu)內(nèi)部網(wǎng)絡(luò)安全連接起來的場合SSLVPN則主要用于遠程終端通過Web瀏覽器訪問內(nèi)部網(wǎng)絡(luò)中的應(yīng)用服務(wù)器（如Web服務(wù)器、電子郵件服務(wù)器等）這一場合SSL/TLSVPN與IPsecVPNSSLVPN自身安全問題擴展討論：SSLVPN安全漏洞擴展討論：SSLVPN安全漏洞SonicWallSSLVPNSMA100SQL注入漏洞(CVE-2021-20016)擴展討論：SSLVPN安全漏洞本章小結(jié)作業(yè)參考內(nèi)容一、SSL/TLS協(xié)議實現(xiàn)正確性問題SSL/TLS協(xié)議實現(xiàn)正確性問題拓展討論SSL/TLS協(xié)議實現(xiàn)正確性問題拓展討論SSL/TLS協(xié)議實現(xiàn)正確性問題拓展討論SSL/TLS協(xié)議實現(xiàn)正確性問題拓展討論SSL/TLS協(xié)議實現(xiàn)正確性問題擴展討論SSL/TLS協(xié)議實現(xiàn)正確性問題拓展討論OpenSSLClientCRYPTO_DOWN_REFUAF漏洞拓展討論拓展討論USENIXSecurity2020利用TLS實現(xiàn)新的攻擊拓展討論二、TCP連接劫持連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議連接劫持：TCP協(xié)議USENIXSECURITY2016連接劫持：TCP協(xié)議USENIXSECURITY2016RFC5961連接劫持：TCP協(xié)議USENIXSECURITY2016連接劫持：TCP協(xié)議USENIXSECURITY2016GeekPwn2016連接劫持：TCP協(xié)議USENIXSECURITY2018連接劫持：TCP協(xié)議USENIXSECURITY2018連接劫持：TCP協(xié)議USENIXSECURITY2018連接劫持：TCP協(xié)議USENIXSECURITY2018連接劫持：T