第7講 傳輸層安全

1、第七講第七講 傳輸層安全傳輸層安全提綱提綱TCP/IP安全方法SSLTLSHTTPSSSHTCP/IPTCP/IP安全方法安全方法TCP/IP協(xié)議協(xié)議 棧中的安全設施的相對位置棧中的安全設施的相對位置Ipsec的好處是對終端用戶和應用是透明的，能提供一種一般性的解決方案SSL或TLS都是可執(zhí)行協(xié)議軟件包的一部分，從而對應用是透明的，Netscape進而IE都配置了SSL。大部分Web服務器都實現(xiàn)了該協(xié)議。SSL (Secure Socket Layer)SSL(Security Socket Layer 安全套接層) 最初1994年Netscape開發(fā),專門用于保護Web通訊.保護瀏覽器和服務

2、器之間的通信,在客戶和服務器之間提供服務器鑒別、可選客戶鑒別和加密通信信道。使用TCP提供一種可靠的端對端的安全服務。版本和歷史 1.0，不成熟 2.0，基本上解決了Web通訊的安全問題Microsoft公司發(fā)布了PCT(Private Communication Technology)，并在IE中支持 3.0，1996年發(fā)布，增加了一些算法，修改了一些缺陷 TLS 1.0(Transport Layer Security傳輸層安全協(xié)議, 也被稱為SSL 3.1)，1997年IETF發(fā)布了Draft，同時，Microsoft宣布放棄PCT，與Netscape一起支持TLS 1.0 1999年，

3、發(fā)布RFC 2246(The TLS Protocol v1.0)功能 客戶端驗證服務器 客戶段與服務器選擇彼此支持的算法 服務器驗證客戶端（可選） 使用公開密鑰算法產生共享的密鑰 SSL連接建立VersionSourceDescriptionBrowser SupportSSL v2.0Vendor Standard (from Netscape Corp.) SSL2First SSL protocol for which implementations exist- NS Navigator 1.x/2.x- MS IE 3.x- Lynx/2.8+OpenSSLSSL v3.0Expi

4、red Internet Draft (from Netscape Corp.) SSL3Revisions to prevent specific security attacks, add non-RSA ciphers and support for certificate chains- NS Navigator 2.x/3.x/4.x- MS IE 3.x/4.x- Lynx/2.8+OpenSSLTLS v1.0Proposed Internet Standard (from IETF) TLS1Revision of SSL 3.0 to update the MAC layer

5、 to HMAC, add block padding for block ciphers, message order standardization and more alert messages.- Lynx/2.8+OpenSSLSSL協(xié)議的版本協(xié)議的版本SSL3.0 增加了對證書鏈加載的支持。使服務器可以將自己的服務器證書和發(fā)行者的證書一起傳給瀏覽器。證書鏈的加載，使得客戶機即使沒有安裝過服務器的中間證書，也可以來驗證服務器證書的有效性，因為服務器的中間證書被放在證書鏈中一起發(fā)送給了客戶機。SSL2.0協(xié)議只適用RSA密鑰交換方式，而SSL3.0不僅支持RSA密鑰交換（在使用證書的情

6、況下），還支持Diffie-Hellman密鑰交換（在沒有使用證書或者沒有客戶端和服務器之間通信密鑰之前的情況下。）7層模型的第4層 (傳輸層） 實際上在四層的上部: TCP 不需要更改操作系統(tǒng) TCP 提供了可靠的消息傳輸SSL協(xié)議的位置協(xié)議的位置SSL協(xié)議可用于保護正常運行于TCP之上的任何應用協(xié)議，如HTTP、FTP、SMTP或Telnet的通信，最常見的是用SSL來保護HTTP的通信。協(xié)議的使用協(xié)議的使用 https:/ 與shttp:/SSL Architecture包括包括SSL記錄協(xié)議和三個高層協(xié)議（握手協(xié)議、密鑰更改記錄協(xié)議和三個高層協(xié)議（握手協(xié)議、密鑰更改規(guī)格協(xié)議、報警協(xié)議）

7、規(guī)格協(xié)議、報警協(xié)議）SSL記錄協(xié)議對各種更高級的協(xié)議提供基本的安全服務。記錄協(xié)議對各種更高級的協(xié)議提供基本的安全服務。SSL connection a transient, peer-to-peer, communications link associated with 1 SSL sessionSSL session an association between client & server created by the Handshake Protocol define a set of cryptographic parameters may be shared by multipl

8、e SSL connections 避免每條連接需要進行的代價高昂的新的安全參數(shù)協(xié)商過程SSL 參數(shù)參數(shù)會話狀態(tài)參數(shù)會話狀態(tài)參數(shù)會話標識符：由服務器產生用于標識活動的或可恢復的會話狀態(tài)的一個任意字節(jié)序列對等證書：對等的X.509V3證書壓縮方法：加密前用于壓縮數(shù)據的算法密碼規(guī)格：大塊數(shù)據加密算法， 計算MAC的散列算法主密鑰：48字節(jié)的會話密鑰可恢復性：能否把會話用于創(chuàng)建新連接的標志比特連接狀態(tài)參數(shù)連接狀態(tài)參數(shù)服務器和客戶端隨機數(shù)：服務器寫MAC密鑰：服務器發(fā)送數(shù)據時用于計算MAC的密鑰客戶端寫MAC密鑰：客戶端發(fā)送數(shù)據時用于計算MAC的密鑰服務器寫密鑰：服務器用于加密數(shù)據、客戶端用于解密數(shù)據

9、的密鑰客戶端寫密鑰：客戶端用于加密數(shù)據、服務器用于解密數(shù)據的密鑰初始化向量：當CBC模式中的數(shù)據塊正在使用時，需要為每個密鑰配置一個初始化向量。之后的IV值為前一次分組密碼算法的最后一個密文分組序列號SSL Record Protocol ServicesConfidentiality 機密性機密性 using symmetric encryption with a shared secret key defined by Handshake Protocol AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128 mes

10、sage is compressed before encryptionmessage integrity 消息完整性消息完整性 using a MAC with shared secret key similar to HMAC but with different paddingSSL記錄協(xié)議記錄協(xié)議每個這樣的段最大為214-1=16383個字節(jié)。從原始數(shù)據段到生成SSL明文分段、SSL壓縮、SSL密文（加密步驟）SSL記錄格式記錄格式SSL記錄頭部包括：記錄頭部包括：內容類型（內容類型（8位）位）-可以是可以是修改密碼協(xié)議、報警協(xié)議修改密碼協(xié)議、報警協(xié)議、握手協(xié)議、應用數(shù)據四、握手協(xié)議、

11、應用數(shù)據四種種主版本號（主版本號（8位）位） 副版本副版本號（號（8位）位）壓縮長度（壓縮長度（16位）位）-以字以字節(jié)為單位的明文分段（壓節(jié)為單位的明文分段（壓縮分段）長度縮分段）長度Content TypeMajor VersionMinor VersionCompressed LengthPlaintext (optionally compressed)MAC (0, 16, or 20 bytes)Encrypted1(a) Change Cipher Spec Protocol1 byte(c) Handshake ProtocolType1 byteLengthContent3 b

12、ytes3 bytes(b) Alert ProtocolLevel1 byteAlert1 byte(d) Other Upper Layer Protocol as TLS PayloadContentUp to 214 + 2048 bytesSSL記錄協(xié)議負載記錄協(xié)議負載SSL修改密文協(xié)議修改密文協(xié)議 協(xié)議由單個消息組成,該消息只包含一個值為1的單個字節(jié)。該消息的唯一作用就是使未決狀態(tài)拷貝為當前狀態(tài),更新用于當前連接的密碼組。 為了保障SSL傳輸過程的安全性,雙方應該每隔一段時間改變加密規(guī)范。 SSL告警協(xié)議告警協(xié)議 為對等實體傳遞SSL的相關警告。如果在通信過程中某一方發(fā)現(xiàn)任何異常,

13、就需要給對方發(fā)送一條警示消息通告。 警示消息有兩種 Fatal錯誤,如傳遞數(shù)據過程中,發(fā)現(xiàn)錯誤的MAC,雙方就需要立即中斷會話,同時消除自己緩沖區(qū)相應的會話記錄; Warning消息,這種情況,通信雙方通常都只是記錄日志,而對通信過程不造成任何影響。 （對警告的內容做了相關的約定）SSL握手協(xié)議握手協(xié)議 1 使得服務器和客戶能夠相互鑒別對方,協(xié)商具體的加密算法和MAC算法以及保密密鑰,用來保護在SSL記錄中發(fā)送的數(shù)據 SSL握手協(xié)議允許通信實體在交換應用數(shù)據之前協(xié)商密鑰的算法、加密密鑰和對客戶端進行認證（可選）的協(xié)議，為下一步記錄協(xié)議要使用的密鑰信息進行協(xié)商，使客戶端和服務器建立并保持安全通信

14、的狀態(tài)信息。SSL握手協(xié)議是在任何應用程序數(shù)據傳輸之前使用的。 SSL握手協(xié)議包含四個階段: 建立安全能力; 服務器鑒別和密鑰交換; 客戶鑒別和密鑰交換; 完成握手協(xié)議。建立安全能力建立安全能力服務器認證和密鑰服務器認證和密鑰交換交換客戶端認證和密鑰交換客戶端認證和密鑰交換完成完成SSL握手協(xié)議細節(jié)握手協(xié)議細節(jié)第一階段 客戶端發(fā)起建立連接請求Client_hello消息 Version：客戶端SSL的最高版本號 Random：隨機序列 32位時間戳+28字節(jié)隨機數(shù)（防重放攻擊），用于生成主秘密。 Session ID :會話ID 非零值表示用戶希望重用現(xiàn)有會話的參數(shù)；零值表示客戶端希望建立新的

15、會話ID并協(xié)商安全參數(shù) CipherSuite : 密碼構件，客戶端可以支持的密碼算法組合（以優(yōu)先遞減順序給出） Compression Method : 客戶端支持的壓縮方法列表 ServerHello信息Version：取客戶端支持的最高版本號和服務端支持的最高版本號中的較低者。Random ：用于生成主秘密的32字節(jié)的隨機數(shù)。（客戶端一個、服務端一個）會話ID： 如果client_hello中的會話ID非零，則差找相應存儲的會話參數(shù)，反饋用原值，為零則產生一個新的會話ID從客戶端的密碼套件列表中選擇的一個密碼套件，若用原會話ID，則直接用相應參數(shù)從客戶端的壓縮方法的列表中選擇的壓縮方法S

16、SL握手協(xié)議細節(jié)握手協(xié)議細節(jié)密碼套件列表參數(shù) 密鑰交換方法（6種：無效（沒有密鑰交換）、RSA、匿名Diffie-Hellman、Ephemeral Diffie-Hellman、Fixed Diffie-Hellman、Fortezza）； 塊加密算法（AES, IDEA, RC2-40, DES-40, DES, 3DES, Fortezza, RC4-40, RC4-128） MAC算法（MD5，SHA-1）Fixed Diffie-Hellman 公鑰證書中包含固定的Diffie-Hellman公鑰參數(shù)Ephemeral Diffie-Hellman Diffie-Hellman公鑰參

17、數(shù)使用發(fā)送者的RSA私鑰或DSS密鑰的方式被交換和簽名，可以獲得一個臨時的被認證的密鑰SSL握手協(xié)議細節(jié)握手協(xié)議細節(jié)列舉JSSE支持的幾個套件：SSL_RSA_WITH_RC4_128_MD5 = 0 x0004 /* 非對稱加密算法或密鑰交換算法為RSA，采用高強度128位對稱加密算法RC4，摘要或MAC算法為MD5，不支持出口 */SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = 0 x0014 /* 非對稱加密算法或密鑰交換算法支持RSA和DH，采用40位對稱加密算法DES，摘要或MAC算法為SHA，可以出口 */ JSSE，即Java(TM) Secure

18、 Socket Extension 。 JSSE是基于安全算法和握手機制之上的合成體。JSSE將危險的安全弱點降到最低點，并且它減輕了開發(fā)者的負擔，使得開發(fā)者可以很輕松的整合到程序中。 SSL(Secure Sockets Layer)是JSSE中的重要的部分。OpenSSL采用C語言作為開發(fā)語言，這使得OpenSSL具有優(yōu)秀的跨平臺性能，這對于廣大技術人員來說是一件非常美妙的事情，可以在不同的平臺使用同樣熟悉的東西。OpenSSL支持Linux、Windows、BSD、Mac、VMS等平臺，這使得OpenSSL具有廣泛的適用性。1998年，OpenSSL項目組接管了OpenSSL的開發(fā)工作，

19、并推出了OpenSSL的0.9.1版，到目前為止，OpenSSL的算法已經非常完善，對SSL2.0、SSL3.0以及TLS1.0都支持。SSL握手協(xié)議細節(jié)握手協(xié)議細節(jié)第二階段 服務器認證和密鑰交換 證書：服務器將數(shù)字證書和到根CA整個鏈發(fā)給客戶端，使客戶端能用服務器證書中的服務器公鑰認證服務器。 服務器密鑰交換（可選）：這里視密鑰交換算法而定 證書請求：服務端可能會要求客戶自身進行驗證。 服務器握手完成：第二階段的結束，第三階段開始的信號SSL握手協(xié)議細節(jié)握手協(xié)議細節(jié)如果協(xié)商過程中確定使用RSA交換密鑰，SSL握手協(xié)議細節(jié)握手協(xié)議細節(jié)證書（可選）：為了對服務器證明自身，客戶要發(fā)送一個證書信息，

20、這是可選的，在IIS中可以配置強制客戶端證書認證?？蛻魴C密鑰交換（Pre-master-secret）：這里客戶端將預備主密鑰發(fā)送給服務端，注意這里會使用服務端的公鑰進行加密。證書驗證（可選），對預備秘密和隨機數(shù)進行簽名，證明自己擁有證書的私鑰。SSL握手協(xié)議細節(jié)握手協(xié)議細節(jié)Client發(fā)送消息給服務器確認將來客戶端將會用會話密鑰,然后客戶端發(fā)送一個消息（加密的）指示服務器客戶端握手部分結束。Server發(fā)送消息給客戶端確認服務器端將會使用會話秘鑰,然后服務端發(fā)送一個消息（加密的）指示客戶端服務器握手部分結束。SSL握手結束，SSL會話開始。C與S使用會話密鑰來加解密相互發(fā)送的數(shù)據以及驗證消息

21、的完整性。Cryptographic Computations master secret creationla one-time 48-byte valuelgenerated using secure key exchange (RSA / Diffie-Hellman) and then hashing info generation of cryptographic parameterslclient write MAC secret, a server write MAC secret, a client write key, a server write key, a client

22、 write IV, and a server write IVl generated by hashing master secret密鑰計算過程密鑰計算過程SSL協(xié)議安全性分析鑒別機制鑒別機制 公開密鑰技術和數(shù)字證書可以實現(xiàn)客戶端和服務器端的身份鑒別。加密機制加密機制混合密碼體制的使用提供了會話和數(shù)據傳輸?shù)募用苄员Ｗo。雙方使用非對稱密碼體制協(xié)商出本次將要使用的會話密鑰，并選擇一種對稱加密算法。 完整性機制完整性機制 定義了共享的、可以用來形成報文鑒別碼MAC的密鑰。數(shù)據進行分片壓縮后，使用單向散列函數(shù)產生一個MAC，加密后置于數(shù)據包的后部，并且再一次和數(shù)據一起被加密,然后加上SSL首部進行

23、網絡傳輸。 這樣，如果數(shù)據被修改，其散列值就無法和原來的MAC相匹配，從而保證了數(shù)據的完整性。 抗重放攻擊抗重放攻擊SSL使用序列號來保護通信方免受報文重放攻擊。這個序列號被加密后作為數(shù)據包的負載。在整個SSL握手中，都有一個唯一的隨機數(shù)來標記這個SSL握手，這樣重放便無機可乘。SSL協(xié)議安全性分析SSL脆弱性分析客戶端假冒客戶端假冒 因為SSL協(xié)議設計初衷是對Web站點及網上交易進行安全性保護，使消費者明白正在和誰進行交易要比使商家知道誰正在付費更為重要，為了不致于由于安全協(xié)議的使用而導致網絡性能大幅下降， SSL協(xié)議并不是默認地要求進行客戶鑒別，這樣做雖然有悖于安全策略，但卻促進了SSL的

24、廣泛應用。 針對這個問題，可在必要的時候配置SSL協(xié)議，使其選擇對客戶端進行認證鑒別。無法提供基于無法提供基于UDPUDP應用的安全保護應用的安全保護SSL協(xié)議需要在握手之前建立TCP連接，因此不能對UDP應用進行保護。如果要兼顧UDP協(xié)議層之上的安全保護，可以采用IP層的安全解決方案。SSLSSL協(xié)議不能對抗通信流量分析協(xié)議不能對抗通信流量分析 由于SSL只對應用數(shù)據進行保護，數(shù)據包的IP頭和TCP頭仍然暴露在外，通過檢查沒有加密的IP源和目的地址以及TCP端口號或者檢查通信數(shù)據量，一個通信分析者依然可以揭示哪一方在使用什么服務，有時甚至揭露商業(yè)或私人關系的秘密。進程中主密鑰泄漏進程中主密鑰

25、泄漏 除非SSL的工程實現(xiàn)大部分駐留在硬件中，否則主密鑰將會存留在主機的主存儲器中，這就意味著任何可以讀取SSL進程存儲空間的攻擊者都能讀取主密鑰，因此，不可能面對掌握機器管理特權的攻擊者而保護SSL連接，這個問題要依靠用戶管理策略來解決。SSL脆弱性分析磁盤上的臨時文件可能遭受攻擊磁盤上的臨時文件可能遭受攻擊對于使用虛擬內存的操作系統(tǒng)，不可避免地有些敏感數(shù)據甚至主密鑰都交換到存盤上，可采取內存加鎖和及時刪除磁盤臨時文件等措施來降低風險安全盲點安全盲點系統(tǒng)管理員不能使用現(xiàn)有的安全漏洞掃描或網絡入侵檢測系統(tǒng)來審查或監(jiān)控網絡上的SSL交易。加密技術使得通過網絡傳輸?shù)男畔o法讓IDS辨認.使得最重要

26、的服務器反而成為受到最少防護的服務器。對此，惡意代碼檢測、增強的日志功能等基于主機的安全策略會成為最后防線。SSL脆弱性分析SSL的評價的評價 SSL仍然不失為一套全面完善的安全策略中有效的組成元素。 然而，與網絡安全的其它工具軟件一樣，僅使用單一的防護軟件都是遠遠不夠的。對SSL的過高評價有可能帶來高的安全風險，它僅僅是網絡安全工具的一種，必須和其它網絡安全工具緊密結合，方能構造出全面、完善、安全可靠的網絡。 傳輸層安全（傳輸層安全（TLS） RFC5246 非常接近于SSLv3 記錄格式與SSL完全相同 不同不同 消息認證碼的計算使用了RFC2104定義的HMAC算法；而SSL也使用相同算

27、法，只是填充部分采用了與密鑰串接的方式而不是異或方式，安全強度基本相同 定義了更多的報警碼 密鑰構建細小差別 TLS不支持Fortezza 密鑰計算HTTPsHTTP 和SSL結合實現(xiàn)網絡瀏覽器和服務器之間的安全通信 ，RFC2818HTTPS和HTTP的區(qū)別 https協(xié)議需要到CA申請證書，一般免費證書很少，需要交費。 http信息是明文傳輸，https 則是具有安全性的SSL加密傳輸協(xié)議。 http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。 http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網

28、絡協(xié)議，比http協(xié)議安全。HTTPs解決的問題解決的問題信任主機的問題信任主機的問題.采用https的服務器必須從CA 申請一個用于證明服務器用途類型的證書。目前所有的銀行系統(tǒng)網站，關鍵部分應用都是https 的?？蛻敉ㄟ^信任該證書，從而信任了該主機。通訊過程中的數(shù)據的泄密和被篡改通訊過程中的數(shù)據的泄密和被篡改一般意義上的https，就是服務器有一個證書。保證服務器是他聲稱的服務器。 服務端和客戶端之間的所有通訊，都是加密的。服務端和客戶端之間的所有通訊，都是加密的。 客戶端產生一對稱的密鑰，通過服務器的證書來交換密鑰所有的信息往來都加密 少許對客戶端有要求的情況下，會要求客戶端也必須有一個

29、證書少許對客戶端有要求的情況下，會要求客戶端也必須有一個證書。除了用戶名/密碼，還有一個CA 認證過的身份。個人銀行的專業(yè)版是這種做法，具體證書可能是拿U盤（即U盾）作為一個備份的載體。SSH（ Secure Shell ）protocol for secure network communicationsldesigned to be simple & inexpensiveSSH1 provided secure remote logon facilitylreplace TELNET & other insecure schemeslalso has more general clien

30、t/server capabilitySSH2 fixes a number of security flawsdocumented in RFCs 4250 through 4254SSH clients & servers are widely availablemethod of choice for remote login/ X tunnelsSSH 是目前較可靠，專為遠程登錄會話和其他網絡服務提供安全性的協(xié)議。利用 SSH 協(xié)議可以有效防止遠程管理過程中的信息泄露問題。S S H最初是U N I X系統(tǒng)上的一個程序，后來又迅速擴展到其他操作平臺。S S H客戶端適用于多種平臺。 幾

31、乎所有U N I X平臺包括H P - U X、L i n u x、A I X、S o l a r i s、Digital UNIX、I r i x，以及其他平臺都可運行S S H。SSH（ Secure Shell ）SSH（ Secure Shell ）SSH Transport Layer Protocolserver authentication occurs at transport layer, based on server/host key pair(s) server authentication requires clients to know host keys in a

32、dvance （客戶端本地數(shù)據庫保存，服務器公鑰或者CA根密鑰） packet exchange establish TCP connection can then exchange data identification string exchange（識別字符串交換）這些字符用于Diffie-Hellman密鑰交換, algorithm negotiation（算法協(xié)商）給出算法清單,包括密鑰交換、加密、MAC算法和壓縮算法（p136） key exchange（密鑰交換）, Diffie-Hellman 服務器用私鑰簽名 end of key exchange, （密鑰生成-協(xié)商后的密鑰

33、做hash運算） service request 請求獲得身份認證 using specified packet format（分組長度、填充域長度、壓縮的有效載荷、SSH User Authentication Protocol authenticates client to server three message types:l SSH_MSG_USERAUTH_REQUESTl SSH_MSG_USERAUTH_FAILURE l SSH_MSG_USERAUTH_SUCCESS authentication methods usedl public-key, 用戶向服務器發(fā)送包含用戶公共密鑰的信息，該信息由用戶私鑰簽名。l password, 信息包含了明文口令，加密l host-based 驗證主機而非用戶本身，一臺支持