SSL/TLS 的近年相關攻擊研究綜述 (二)

文/韋俊琳

SSL/TLS 的近年相關攻擊研究綜述 (二)

文/韋俊琳

編者按：在SSL／TLS的協議設計中，除了CBC模式，RC4之外，近幾年還發現了一些其他相關的漏洞。在K. Bhargavan團隊的相關研究中，三次握手攻擊，SLOTH攻擊，降級彈性等都是有代表性的研究。同時，在發現漏洞的工程中，研究人員還通過利用自動狀態機來發現漏洞，具有很強的影響力。

三次握手攻擊

三次握手攻擊，利用的漏洞是協議的設計問題，主要是利用TLS協議的RSA／DH密鑰交換缺陷和會話恢復的缺陷來繞過防護措施。作為TLS會話的核心，會話的主密鑰是經過客戶端驅動產生的。客戶端會生成預主密鑰和一個隨機值發送給服務器，而服務器也會生成一個隨機值發送給客戶端，并且，預主密鑰是加密傳輸的，根據客戶端和服務器端的三個值生成主密鑰。

SLOTH攻擊

對于MD5和SHA-1的碰撞，很多實踐者認為，它們在這些協議中的使用僅依賴于第二前級映像，不受碰撞的影響。作者在[2]中則是系統地進行研究和揭示這個論點的薄弱，并在密鑰交換協議上設計出一類新的基于哈希結構的有效的沖突查找算法的碰撞攻擊。通過在TLS1.2客戶端身份驗證上進行演示攻擊和幾乎現實化的TLS1.1，IKEv2和SSH-2的降級攻擊，迫使多個TLS庫進行更新，禁用主流協議中的弱哈希函數。其中SLOTH(security losses from obsolete and truncated transcript hashes)是攻擊者迫使使用弱哈希算法，如客戶端TLS1.2版本可以利用MD5進行降級攻擊。在握手的初期，客戶端將Client Hello數據包發生給服務器；數據包中聲明了服務器可以使用的簽名和加密算法。然而，攻擊者可以截獲該數據包，并且向客戶端發送一個要求更改算法的數據包，迫使客戶端接受。至此，攻擊者就開始了冒充目標服務器的攻擊過程。位于客戶端和服務器端之間的攻擊者通過發送Server Hello、Certificate和Server Key Exchange數據包響應客戶端請求。在Server Key Exchange中，攻擊者使用RSA-MD5算法替換客戶端實際指定的算法。客戶端接收到“服務器端”的響應，并最終使用弱哈希算法。隨后，客戶端再次發送Client Key Exchange響應，握手成功。TLS被降級后，中間人攻擊者就可以冒充服務器，解密所有加密的流量。SLOTH也可以反向進行，導致服務器端被使用MD5降級攻擊。針對這個攻擊，最好的方案是在TLS1.2 后的版本中刪除MD5／SHA-1等弱哈希算法的支持，當然對于SSH和VPN也需要進行同樣的更改。[3]

降級彈性

降級攻擊是攻擊者使用一些策略，讓服務器和客戶端采用比較弱的協議或者加密方式的一種攻擊。類似于TLS，SSH，IPsec和ZRTP之類的密鑰交換協議是高度可配置的，能夠支持多種版本的協議，加密算法和參數等。這也是為了讓協議能夠具有更好的應用范圍，所具備的敏捷性。作者在[4]中設計了一個正式的框架來研究降級彈性及其與密鑰交換協議的其他安全屬性的關系。通過剖析和歸類經典攻擊和一些新型攻擊，總結其中的原因，并調查現有的標準降級彈性的相關內容，然后將這些結果與降級安全性結合起來，分析幾個協議實現的條件，最后設計一套降低安全性的模式，并解釋如何使用它們來加強現有協議的安全性。

論文中再次提及到Agility，現代協議具有加密敏捷性，其提供了多種協議和密碼模式的可配置選擇，使得在兩個對等體之間實際執行的密鑰交換取決于嵌入在交換中的協商階段。在確保實際的協議實現方面，敏捷性已被證明其重要性。不幸的是，對算法敏捷性的支持為降級攻擊提供了機會，在這種攻擊中，主動網絡攻擊者干擾協商，導致誠實的對等方完成密鑰交換，盡管使用的方式比自己使用的模式弱。為了防止對特定協議模式的攻擊，關閉導致其協商的配置也是必要的。作者對降級彈性的探討依然是建立在mi TLS上的，考慮Initiator 和 Responder，引入了一個降級保護謂詞DP，它可以對成對的配置進行操作，并且確定了一組配置來降低彈性。還引入了一個函數Nego，將兩個相反角色的配置映射到協議模式，在沒有攻擊者的情況下應該協商。而且如果從符合DP的配置開始的兩個對等體只能協商Nego確定的模式，即使在有攻擊者的情況下，協議也會降級安全。例如，對于TLS協議，Nego的具體實例可能會確定兩個TLS對等體配置通常會導致TLS 1.2與密碼套件的協商，例如DHE-RSA-AES256-GCMSHA384，具有2048位DH模數。但是，如果服務器支持不安全模式，例如DHEEXPORT密碼套件，則對手可能會迫使其降級到此模式。這表明如果沒有其他對策，TLS 1.2將不符合的定義。另一方面，僅具有一種可能模式的協議顯然是安全的。[4]

作者也證實了TLS1.2版本協議并不是降級安全的，還描述了IKEv2和ZRTP的新的降級漏洞，并提出相應的配置方案來避免這些漏洞，最后還證明了SSHv2是降級安全的。

利用狀態機檢測漏洞

SSL／TLS協議的設計是非常復雜的，其中在一些RFC的定義并沒有被很好地實現，或者說在實現過程中存在偏差，導致存在著一些致命的漏洞。近幾年有很多研究人員對TLS的實現做了深入的研究，如OpenSSL，MatrixSSL等，發現了一些比較有意義的漏洞，如HeartBleed，FREAK等。在發現漏洞的工程中，研究人員開發了很多新的方式，其中利用自動狀態機來發現漏洞的方式就具有很強的影響力。

在TLS實現中，還存在著很多細節的問題需要解決。在[5]中，作者研究TLS握手的可驗證安全性。通過mi TLS驗證了許多協議版本，配置和密碼套件的主流瀏覽器和服務器的互操作性，并為其提供了在應用層可證明的安全性。在TLS協議的實現中，必須處理各種版本協議和相關的擴展，認證模式和密鑰交換的方法，而不同的組合在客戶端和服務器端之間又形成了不同的消息序列。作者在[6]中設計復合狀態機來解決不同協議模式之間的細節問題，通過系統測試一些流行的開源TLS，發現了多年來隱藏在這些庫里面的幾個關鍵性安全漏洞。自動狀態機是第一個用C語言寫的，進行過驗證的TLS狀態機綜合實現，并且可以嵌入到OpenSSL中進行使用。利用論文中的方法可以對密碼協議庫的核心組件進行形式化驗證。

經過20年的演變，TLS具有很多版本、擴展和密碼套件，而且其中一些已經不被使用或者已經被確認為不安全。但是，客戶端和服務器端的實現要保證具有靈活性，互操作性，導致它們的部署中通常會支持不安全的密碼套件。當然握手期間的TLS會話的特定參數會通過MAC來驗證，確保不會被篡改，而且如果客戶端或者服務器端僅支持安全協議版本，那不管對等方支持什么不安全的套件，也只能和安全方保持一致。而在具體的實現中，就TLS1.0～TLS1.2而言，有一些細節地方不能被忽視。首先，協議中消息順序是精心設計的，從互操作性和安全性的角度是不能隨意更改的，比如ServerCCS消息就必須在ServerFinished消息之前發生。其次，客戶端和服務器端必須要能區分真正可選的消息，而不是簡單的線性接收和發送，類似于區分ServerNewSessionTicket和當前密鑰交換消息。然后，不能過早地計算會話參數和密鑰，客戶端應該在接收到服務器的消息后才確認握手過程。還有一些版本的協議，如SSLv23，DTLS都存在一些細節問題，在SSLv3中，客戶端可能根本不發送ClientCertificate消息，而DTLS則允許服務器使用新的HelloVerifyRequest消息來響應ClientHello。在TLS庫中，還實現了許多在網絡上不常用的密碼協議，如PSK，DH anon／ECDH anon，DHE PSK等，使用這些密鑰套件時需要一些額外的協商參數。而對于重協商，在同一個連接上建立多個TLS握手，從邏輯上看，非常清晰，但是實現起來就相當棘手，也就導致了很多利用重協商漏洞的攻擊。

雙簇頭機制無線傳感器網絡中，主副簇頭在射頻模塊配置相同的情況下能夠同時接收到節點的檢測信息。當副簇頭在在接收到4個傳感器節點數據后會開啟定時器，在定時結束之前，如果接收主簇頭廣播的信息，則副簇頭作為普通節點接收數據融合結果。否則，副簇頭根據接收的節點檢測信息完成數據融合，并將網絡檢測結果廣播到網絡內實現聲源檢測結果的共享。

作者利用[7]中開發的FLEXTLS工具來驗證這些實現中的漏洞，該工具是建立在miTLS上，經過驗證的TLS實現。利用強大的消息傳送和密碼庫，FLEXTLS能夠用來評估協議的漏洞。使用該工具，發現最近的對TLS實現的攻擊，如SKIP和FREAK，以及為FREAK和Logjam提供第一個驗證演示。在[6]中，作者也應用了FLEXTLS工具來進行評估驗證，測出很多細節漏洞。如OpenSSL中EarlyCCS(CCS嚴格意義上不是handshake message，不出現handshake log中，不受客戶端或服務器端狀態機控制，可以出現在ServerHello后的任意位置, 中間人通過在ServerHello之后向對方注入CCS消息，提前設置弱記錄密鑰，然后讓他們完成握手,攔截合法的CCS消息), DH Certificate(client忽略ClientKeyExchange，可能導致client impersonation attack), Server-Gated Crypto(SGC允許客戶端收到serverhello后重新握手，但是表明某些extension是否被使用的信息會在新握手中消失), Export RSA(512位弱簽名)，Static DH(使用DHE或者ECDHE時，如果證書包含ECDH公鑰，而且客戶端不接受ServerKeyExchange，則會回滾到static ECDH，用服務器證書的公鑰，導致前向安全性丟失)。還有JSSE相關問題，如Client flaws(處理特定于某些密碼的可選消息，客戶端和服務器狀態機都允許跳過消息，導致 server impersonation attack), Server flaws(JSSE 服務器類似的允許客戶端跳過消息)。還有一些關于NSS，Mono，CyaSSL和GnuTLS相關漏洞。這個狀態機發現了很多實現過程中存在的漏洞，作者也對大部分漏洞進行了測試，驗證漏洞的存在，并針對性的提出改進建議。

心臟出血

Heartbleed是OpenSSL實現上存在的漏洞，通過發送特殊信號Heartbeat 給服務器，來查看服務器是否在線，當服務器在線時，會發送回復信息給主機，然后允許進行安全通信，服務器和主機會間斷性地發送這個信號確保對方是否在線。心跳包設計之初是為了能夠解決及時檢測連接狀態問題，相比TCP的keepAlive機制具有更大的靈活性，可以自己來控制檢測的間隔和檢測的方式。[8]

心臟出血漏洞最先是被谷歌安全中心的Neel Mehta提出來的，代碼實現中沒有對內容分配的限制，攻擊者能夠利用Heartbeat發送惡意信息給服務器，強制OpenSSL服務器讀取任意內存位置，攻擊者還能夠控制心跳的大小和結構，然后利用TCP協議，在443端口接收請求，一次可以收到64kb的服務器內存數據，多次請求，攻擊者能夠得到更多的服務器內存信息，有可能包括大量的郵件地址，密碼等信息。OpenSSL從1.0.1版本到1.0.1f版本都廣泛存在心臟出血漏洞，可想而知，數量巨大的服務器都會受到影響，根據Netcraft估計，17%的服務器都受到了影響，大約在50萬臺。

當然最致命的是攻擊者可以用這種方式來獲取加密密鑰，泄漏的密鑰允許攻擊者解密過去和未來的相關流量，并且可以隨意假冒服務。而且X.509證書中的加密和簽名提供的保護都可以被繞過，那么從此泄漏中恢復需要修補漏洞，并撤銷被泄漏的密鑰，重新發布和重新分發新密鑰。即使這樣做，攻擊者仍然可以解密過去攔截的流量，這些都必須由服務的業主來完成。

對該問題的解決最有效的方式是打補丁，可以選擇升級OpenSSL版本，也可以配置OpenSSL協議來刪除對心跳協議的支持。由于攻擊者可能獲取到密鑰，所以最好替換私鑰，并且要想保證過去的加密信息無法被泄漏的服務器私鑰影響，可以部署具有前向保密性的加密方式。

Freak 和 Logjam

繼Heartbleed 后，OpenSSL又被公布了Freak（Factoring RSA Export Keys）漏洞，雖然這個漏洞的影響沒有Heartbleed影響力那么大，但是很容易被中間人利用遭到中間人攻擊。該漏洞源自于20世紀90年代，美國限制出口高強度的加密算法，限制加密強度最大為40位，密鑰交換強度最大為512位。從現在的計算速度來看，這個出口密碼套件的安全強度是非常弱的，任何人都可以在幾小時內完成破解。進行FREAK攻擊，需要克服兩個障礙，首先被注入的消息需要被目標服務器上的強RSA簽名，然后為了修改TLS握手的消息，攻擊者需要偽造Finished消息，使得對消息的修改變得合法化。完成這個中間人攻擊：

1.在ClientHello 中要求一個標準的RSA密碼套件；

2.MITM攻擊者將服務器消息改為“export RSA”；

3.服務器使用512位export RSA進行響應，并使用其長期密鑰進行簽名；

4.根據OpenSSL 的漏洞，客戶端會接收這個弱鍵；

5.攻擊者對這個弱RSA進行破解，恢復RSA解密密鑰；

6.當客戶端將發送預主密鑰給服務器時，攻擊者變可以解密它，恢復出TLS主密鑰；

7.攻擊完成，可以注入任意內容。

實際上不僅僅是OpenSSL收到這個攻擊的影響，Android系統很多使用的OpenSSL庫都存在了風險，而且隨著攻擊面的擴大，Apple的SSL／TLS（Secure Transport）和Microsoft的SSL/TLS庫（Schannel）也收到了影響。對于Freak漏洞，只有建議各服務移除對出口密碼套件的支持，因為這是這個攻擊的必要條件。

在FREAK攻擊之后，人們就把注意力集中到存在類似問題的Diffe-Hellman密鑰交換算法上，把弱密鑰交換機制進行移植，從而發布了新的漏洞Logjam。這個攻擊復制了Freak攻擊的原理，把RSA_ export 替換成DHE_export。和FREAK不同的是服務器要愿意使用不安全的DH參數，還需要緩存臨時的DH密鑰，最后還要求客戶端能夠愿意接受這些弱DH參數。所以最重要的原因就是瀏覽器能夠接受不安全的DH參數。實際上，攻破1024位參數的攻擊者能夠對6.56%的HTTPS服務器進行被動攻擊，攻破了10個通用組的攻擊者能夠對約10%的服務器進行攻擊。對于SSH，攻破一個標準組，能夠使用被動攻擊約360萬的服務器，而IPsec則能攻擊超過60%的服務器，影響力非常巨大。

緩解這個攻擊其實也不難，首先禁用出口套件，然后升級DHE的套件，確保使用的是2048位而不是1024位，或者完全禁用DHE算法。

證書相關研究

SSL使用的證書是由CA簽發的，基于可信的第三方來保證通訊的安全。在以前只有少數幾個證書頒發機構的時候，可以通過保證自己的根證書的安全來保證頒發的證書的安全。但是，隨著目前市場上的證書頒發機構增多，頒發的要求也參差不齊，導致有不少偽造的證書在被使用，嚴重威脅到了通信安全。

近年來，有不少對檢測偽造證書的研究。在[9]中，作者利用Flash Player 的插件設計和應用了一套針對全球知名網站Facebook的SSL 中間人攻擊檢測，分析了超過300萬以上條實時的SSL連接，發現存在0.2%左右的SSL連接是使用的偽造證書。其中有大量的防毒軟件，內容過濾器，也有一些是惡意軟件使用的不合法證書。之前存在大量的商業證書機構都或多或少被欺騙發布過不合法的證書，這種情況下很多標準的瀏覽器也無法簡單地區分出這些證書。但是更多的情況是用戶忽略瀏覽器給出的警告信息，繼續訪問危險網站。有一些研究人員認為應該忽略掉證書過期的問題，他們表示證書過期是一件很常見的事情，如果經常給用戶提示，會降低用戶對警告的重視性。但是這樣會導致一些偽造的過期證書被允許通過，也會帶來嚴重的安全隱患。作者對收集到的偽造證書進行了特征分析，其中大部分的偽造證書非常小，通常沒有超過1KB，只有很少部分超過5KB。而且偽造證書鏈比較短，鏈長大部分為一，通常是一些self-singed證書，極少含有中間證書。通過分析偽造證書的Subjects，發現大部分采用的是合法的域名，只有少部分使用的一些不相關的域名。其中大部分偽造證書都是選擇好目標后，預先生成，而不是復制Facebook的合法證書。檢查Issuers時，發現大量的偽造證書來源于防毒軟件，防火墻，廣告軟件和惡意軟件。實際上，在[10]中，作者分析了存在于TLS代理中的這些用于過濾TLS流量的防毒軟件和父進程控制應用程序，并設計了一個集成框架來分析這樣的客戶端TLS代理。通過系統分析發現，其中一些工具嚴重影響其主機上的TLS安全性，還發現多個產品容易受到在中間人攻擊的情況下完全服務器代理，并且如果啟用TLS過濾，則還會更可能被攻擊。其中的一些工具還誤導瀏覽器，使其相信這樣的TLS連接比實際更安全。通過檢測發現，在實際的網絡中，不安全的證書是確實存在的，而且存在的數量還不少。

網絡中存在大量的偽造證書，導致受SSL保護的HTTPS看起來似乎也沒那么安全了。證書安全是SSL協議安全的一個重要部分，而客戶端正確驗證服務器端發送的證書的有效性起著至關重要的作用。Chad Brubaker在[11]中提出了一種大規模測試證書在SSL實際應用中的有效性的方法。對真實證書片段增添一些限制和延展，利用“Frankencerts”合成不同的組合證書，并進行“差分測試”。也即在實際SSL應用中，發現一個證書被部分機構接收而被部分機構拒絕，就可以作為差異篩選條件，提取出來進行查詢，用來發現其中存在的漏洞和不足。差分測試使用Frankencerts，涵蓋了208個區別點，涉及的SSL應用包括OpenSSL，NSS，CyaSSL，GnuTLS, PolarSSL, MatrixSSL等。發現了在實際應用中存在著很多的問題，如MatrixSSL會接收X.509 v1版本的證書，使得所有使用MatrixSSL的應用都能被中間人攻擊。攻擊者只需要一個有效的X.509 v1證書就可以偽裝成中間證書發布者，發布一些假的證書，并逃過MatrixSSL的檢查。在GnuTLS中，也存在X.509 v1證書的相關漏洞，由于兩個標志的錯誤匹配，導致可以接收本地可信的X.509 v1證書，即使是來自惡意服務器的證書。更嚴重的漏洞是來自于錯檢和漏檢根證書對下層證書的限制。當然攻擊能夠實現的很重要的部分是用戶忽略掉瀏覽器的提示，堅持訪問不安全的網站，使得攻擊者可以利用大量用戶忽略證書過期的問題，偽造相應證書來完成中間人攻擊。

X.509證書在實際應用中也存在不少的問題，驗證證書的有效性涉及到解析ASN.1的數據結構并解釋內容信息，過程比較復雜，也很容易出錯。但是X.509證書被大量使用，從而具有不可替代性。為了應對X.509證書的一些結構和應用不足，Antoine提出了Cinderella來改善X.509證書的使用。通過應用程序接收并驗證證書完整性，有效性和一致性，取代之前的接收驗證證書鏈的方式。這樣省略證書產生更小的信息，隱藏證書內容具有更強的隱私性，嵌入一些額外的檢測將具有更好的完整性。通過編寫X.509 模版來編寫應用程序的新格式，使用Geppetto加密編譯器為該策略生成零知識可驗證計算方案。并為RSA-PKCS#1簽名和ASN.1解析開發新的C庫，提高加密可驗證性能。在實際的應用中，對TLS支持細粒度驗證策略，通過撤銷檢查和選擇性披露證書內容，有效地將X.509證書轉換為匿名證書。Cinderella利用可驗證計算彌補了現有X.509基礎設施和現代密碼學之間的差距，并且能夠使用戶在較高級的應用程序中重用現有的證書鏈和簽名機制，與現有的基礎設施完美集成，不需要直接訪問X.509簽名密鑰，使其與現有的基于硬件的解決方案兼容。Cinderella提高X.509身份驗證和授權決策的靈活性，表達能力和隱私權，增加了“加密能力”。其中一個給定的驗證策略可以將收集和驗證最近的非撤銷證據的責任移動到證書持有者，使驗證者的撤銷檢查更簡單和更高效，比較好地解決了CRLs和OCSP在線檢查撤銷狀態的難題。

實際上，對于證書的有效性問題，研究人員提出了很多加強SSL安全的方法，如采用HTTP Strict Transport Security(HSTS)來遏制SSL剝離;使用The Public Key Pinning Extension for HTTP(HPKP)允許網站使用HTTP標頭指定自己的公鑰，并指示瀏覽器拒絕具有未知公鑰的任何證書;使用TLS Origin-Bound Certificates(TLSOBC)來封鎖存在的很多中間人攻擊插件；采用DNS-based Authentication of Named Entities（DANE），依賴與DNSSEC阻止偽造修改DNS記錄來使使瀏覽器只接受一些特定的證書；Google提出并發布的證書透明性，可以實時檢測偽造證書。有很多的想法和建議提出來解決證書問題，但是真正用于實踐卻比較難。Adam Bates提出了一些能及時解決目前存在的部分代碼漏洞的方案，引入了對SSL實現的輕量級改進的CERTSHIM，以程序透明的方式來防止SSL漏洞，充當動態鏈接驗證過程中的透明庫。CERTSHIM具有良好的可擴展性，能融合Convergence，DANE和基于客戶端的密鑰固定等方法，并且只帶來極少的延遲。利用CERTSHIM解決了部分遺留在數據庫中的危險代碼問題，也為后面的研究指明了方向，更是促進了證書驗證的發展。

（責編：楊潔）

[ 1 ] K. Bhargavan, A. Delignat-Lavaud, C. Fournet. Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS. In IEEE Symposium on Security and Privacy (Oakland), 2014

[ 2 ] K. Bhargavan, G. Leurent. Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH. In Network and Distributed System Security Symposium (NDSS), 2016

[ 3 ] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud. A Messy State of the Union: Taming the Composite State Machines of TLS. In IEEE Symposium on Security and Privacy (Oakland), 2015

[ 4 ] K. Bhargavan, C. Brzuska, C. Fournet. Downgrade Resilience in Key-Exchange Protocols. In IEEE Symposium on Security and Privacy (Oakland), 2016

[ 5] K. Bhargavan, C. Fournet, M. Kohlweiss. Proving the TLS Handshake Secure (As It Is). In CRYPTO, 2014

[ 6 ] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud. A Messy State of the Union: Taming the Composite State Machines of TLS. In IEEE Symposium on Security and Privacy (Oakland), 2015

[ 7 ] B. Beurdouche, A. Delignat-Lavaud, N. Koberssi. FLEXTLS: A Tool for Testing TLS Implementations. In USENIX Workshop on Offensive Technologies (WOOT), 2015

[ 8] Z. Durumeric, J. Kasten, F. Li. The matter of Heartbleed. In ACM, 2014

[ 9] H. Lin-Shung, A. Rice, E. Ellingsen. Analyzing forged SSL certificates in the wild. In IEEE Symposium on Security and Privacy, 2014

[ 10 ] X. Carne Carnavalet and M. Mannan. Killed by proxy: analyzing Client-end TLS interception software. In NDSS, 2016

[11 ] C. Brubaker, S. Jana, B. Ray. Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations. IEEE Symposium on Security and Privacy, 2014

為清華大學）