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

文/韋俊琳

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

文/韋俊琳

學術專欄

編者按：如今，人們依靠的手機和計算機通信、支付、信息交流等都是互聯網的一部分。眾所周知，在最初設計互聯網時，其主要目標是增強通信能力，沒有過多考慮安全問題。因此，目前互聯網的核心通信協議 TCP/IP，在本質上是不安全的。為了解決數據在 TCP 上的安全傳輸問題，Netscape 公司在 1994 年提出了 Secure Socket Layer (SSL)協議，又稱套接字安全協議，之后 IETF 成立 Transport Layer Security(TLS) 工作組，基于 SSL3 設計了 TLS。SSL/TLS 在協議設計方面，存在一些可以被利用的弱點。本文綜合介紹 SSL/TLS 使用 CBC 及 RC4 加密模式時，可能產生的攻擊。

目前，TLS 已經作為一種工業標準大量應用于網絡交易，信息交流中。例如 HTTPS就是使用 TLS協議進行加密傳輸HTTP流量，旨在為HTTP客戶端（如瀏覽器）和Web服務器之間，創建一條安全的連接，用來保證數據傳輸的私密性和完整性。當客戶端和服務器都同意使用TLS協議時，他們會通過握手來建立安全連接，一個完整的 TLS 握手過程如圖1 所示。

隨著 TLS 的廣泛應用，關于 TLS 安全的研究也越來越多，越來越深入。在這些針對TLS的安全研究中，發現了許多可以被利用的漏洞，這些基于 TLS 的問題大致可分為以下幾類。

TLS所采用的加密算法的漏洞。例如早期設計基于 CBC 模式的一系列加密方式，給現在帶來很多的問題，形成了一系列的漏洞。還有 RC4之類的弱加密算法，也帶來嚴重的漏洞。

TLS 版本兼容帶來的漏洞。由于過時的協議如 SSL3，不能及時退役，對新版本的協議也造成了很嚴重的影響。例如利用降級攻擊，讓通信雙方使用舊版本，從而攻擊雙方的會話，還有 DROWN 攻擊利用 SSLv2 協議對大量服務器進行攻擊，造成很嚴重的影響。

TLS實現的漏洞。由于 TLS的開發人員，沒有嚴格按照TLS協議的標準規范來實現，或者程序本身實現有問題，導致了很多 TLS相關的漏洞。

TLS 所使用的數字證書的相關漏洞。證書管理和驗證的復雜性，也導致了一系列針對證書的相關攻擊，偽造證書，過期證書的清除工作較難解決。

CBC加密模式

在 SSL 協議較早的版本中，大量使用 CBC 分組加密的模式對數據加密，如圖2所示，加密解密過程都是分塊進行。在實際應用中，當明文最后一塊內容不足時，會進行填充。根據填充的內容，Serge Vaudenay 在 [1]中引入了 padding attack，從理論上證明了利用填充內容進行攻擊的可能性，闡述了在 SSL/TLS、IPSEC、WTLS和 SSH2 中使用 CBC 模式具有嚴重的安全隱患。

在CBC模式下，明文會被分割為固定大小的塊。如果明文內容最后一塊不足整塊大小，根據 PKCS#5，會在最后一塊中進行填充，構成完整的塊；如果剛好具有塊大小，則填充一個整塊。CBC模式加密通過塊密鑰和初始向量來加密明文塊，其中明文的每個塊都會和先前的密文塊進行異或運算，每個字符只和每個塊的對應位置相關。為了保證對同一明文加密后的密文不同，其初始向量通常是隨機生成的。

進行密文解密時也是分段進行的，解密完成之后通常會檢查是否符合規則，如果不符合，則會拋出 Padding error異常，提示填充不正確。如果攻擊者獲得了合法的密文，可以通過不斷的向服務器發送篡改的信息，通過觀察服務器返回的信息，即可知道構造內容是否正確。如果收到錯誤提示信息，則再進行修改，從查詢中，試探出IV 的內容，然后通過中間密文逆向解析可以得到明文。當然這樣需要做大量的查詢，一般情況下，攻擊還是很難成立的。當利用填充內容的特性時，攻擊就會變得高效很多。如 Lucky Thirteen，POODLE attack 等都利用了 padding 內容的特性來提高攻擊的效率，使攻擊具有更強的實用性。

Lucky Thirteen 攻擊

圖2 CBC 模式加密解密

利用填充的不確定性，攻擊者能夠通過修改填充的內容來進行測試。AlFardan 和 Paterson 在 [2]中公布了 Lucky Thirteen 攻擊。Paterson 表示，攻擊者作為中間人攔截 TLS 數據包，并對數據包進行篡改，由于傳輸給服務器的數據包具有特殊的排列方式，其中的一個包頭域含有 13 字節，所以命名為“幸運 13”。

該攻擊用來破解小塊的CBC 加密數據，這是一種針對TLS記錄協議的時間側信道攻擊，要求 TLS 記錄協議采用 MEE ( MAC-Encode-Encrypt ) 方式和分組密碼的 CBC 模式。引發攻擊的最重要原因是填充，使用CBC模式，并且利用TLS完整性保護機制。攻擊者可以通過修改填充字節并觀察服務器做出的響應和響應時間，從而提取相關信息，判斷修改的內容是否正確。根據作者的描述，TLS協議會將錯誤的填充在MAC檢測時當作零字節的填充，這個過程比正常協議解密的過程要短很多，產生了一個時間差。檢測時這個較小時間差可以被利用，作者也用實驗證明了確實能夠被利用。雖然實驗中會存在各種因素的偶然對準，如MAC標簽的大小，密碼塊大小和報頭字節的數量等，但是對于處理 TLS 記錄所花費的時間上存在的時間差影響并不是很大。對于好的和壞的填充，這種差異最終將體現在錯誤消息出現在網絡上的時間。這種利用時間的側信道攻擊在實際攻擊中有廣泛的應用，并具有一定程度的威脅性。

作者在文中提出的解決措施是添加隨機時間延遲，使用 RC4，或者使用認證加密和仔細應用 MEE-TLS-CBC 解密方式。在這些方法中，使用 RC 4 代替加密方式是不可取的，RC 4 在近年來發現存在的被充分利用的嚴重漏洞，這種方式只會轉移漏洞到 RC 4 上。而增加時間延遲總體上會造成較長的延遲，而且這個延遲的影響足以抵消它所帶來的好處，犧牲較高效率來換取安全的方式可能不是很好的選擇，所以增加隨機時間延遲的方式也是不可取的。而使用認證加密則是選擇較安全的加密方式，但是認證加密只在 TLS 1.2版本上有添加，對低版本的TLS協議不能有效的解決。作者重點介紹的仔細應用 MEE-TLS-CBC 解密方式，核心的思想是確保一個對于 MEE-TLS-CBC 密文固定大小具有相同的處理時間，把重點放在處理密文上，而不是明文部分，如塊長度或者其它長度信息，修改了 TLS的解密方式來移除時間側信道的影響。

POODLE 攻擊

如果對填充內容不做限定，那么CBC模式的缺陷將被放大，利用填充的最后一個字節固定為填充長度的特性，攻擊將變得更為可行。2014 年 10 月，Google 安全團隊公布了 POODLE(Padding Oracle On Downgrade Legacy Encryption)，這是針對 SSLv3 版本協議的漏洞，可以讓攻擊者破解小段的加密數據[3]。不同的瀏覽器對于 SSL 握手失敗后采取的行為不同，服務器端在協議握手匹配失敗后，會采取降級的措施。如表1(內容來源于《HTTPS 權威指南》)所示，開始握手時服務器會選擇最高的協議版本給客戶端，若握手失敗，服務器會重試舊版本的協議，最后很可能被降級到SSL 3 版本。而且存在類似 Windows 上的 IE 6 瀏覽器只支持 SSL 3。攻擊者也可以用這種對協議的兼容性使握手降級到 SSL 3，然后進行 POODLE 攻擊來劫持會話。

造成POODLE 攻擊的根本原因也是CBC 模式在設計上的缺陷，CBC只對明文進行了身份驗證，而沒有對填充字節部分進行完整性驗證。SSL 3 在填充方式上是保留密文的最后一字節，填寫為填充的長度。但是，規范中沒有規定的填充的具體數據內容，也沒有被MAC驗證，所以就沒有規則來確認填充的內容是否被篡改過，只能驗證填充的長度是否正確。這樣一來，SSL 3 的填充就產生了嚴重的不安全性。

在進行 POODLE 攻擊時，攻擊者能夠截獲密文，正常情況下，直接修改填充字節的內容的方法是不可行的，因為如果改變了MAC值時會引發錯誤，只有當最后整個塊都是填充數據時，攻擊者才能夠可以進行自由的修改并且不會導致MAC校驗的失敗。正常情況下，攻擊者盡管對密文只做了一位修改，也會導致密文解密發生大量的變化，而且解密后的內容也會變成隨機內容。實際上，SSL 3 在做解密校驗時，只需最后的填充長度字節是正確的。在每次攻擊嘗試時，攻擊者將需要解密的塊移至最后一塊，然后修改倒數第二塊的最后一個字節進行查詢，一直重復修改直到服務器成功接收修改后的內容。攻擊的主要思路是攻擊者針對較大的的URL和較小的請求體，通過縮短URL，每次一個字節，直到找到正確填充長度。通過提交足夠多次的修改來破解一個字節，最后同步修改URL內容和請求體的大小并循環破解剩余部分。攻擊的主要原理是數據塊最后一個字節解密后的值為 15（假設塊大小為 16）

表1 瀏覽器自動降級

面對這個嚴重的漏洞，Chrome 和 Firefox 等瀏覽器都禁止回退到 SSL3，IETF 也出臺相應的方案來應對 POODLE 攻擊。根據標準化的防降級方法，瀏覽器可以采用一個特殊的信號套件 TLS_FALLBACK_SCSV 信號，當信號值改變時，瀏覽器能夠通知服務器自己被降級了。這個方案不僅是為了解決 SSL 3 的POODLE 攻擊，而且是為了長期解決降級攻擊問題提出的增添防降級信號。這個攻擊的出現實際上大幅度推進了 SSL 3 的禁用，促使服務器采用更安全的協議，使用更安全的加密方式。

Bleichenbacher 攻擊

當然填充的方式多種，而具有固定格式編碼的 PKCS也會受到填充的影響。Wagner 和 Schneier 在論文 [4]中描述到，攻擊者能夠通過修改 ClientHello 信息，使 SSL 3 版本看起來像 SSL 2 版本的 ClientHello 信息，強制服務器使用漏洞更多的SSL 2。作為應對，他們提出了把版本信息包含在 PKCS 編碼ClientKeyExchange 的 PreMasterSecret 信息中，PKCS 編碼格式見表2。

但是這種編碼方式具有固定的格式，可以被利用來解析數據信息內容。Daniel Bleichenbacher在 [4]中提出了新的攻擊(Bleichenbacher attack)?；?RSA 的 SSL 密碼套件方式，利用PKCS#1 的標準格式在可接受的時間內解密預主密鑰內容。預主密鑰是客戶端使用RSA 密碼套件時生成的隨機值，使用服務器公鑰加密后傳送給服務器。服務器通過私鑰解密后，能夠獲得一份和客戶端相同的預主密鑰和隨機值，其前兩個字節為版本號。攻擊者能夠竊聽加密密文，應用 Bleichenbacher攻擊到 SSL 3，通過接收服務器返回的不同錯誤信息來辨別修改的正確性。

Bleichenbacher攻擊可以識別在 0x00 02 后以明文開始的密文信息，然后進行 Padding Oracle 攻擊來解密預主密鑰，進一步可以取得 SSL 的會話密鑰。充分利用 0x00 02 開頭的特性，假設攻擊者獲得密文 C0，想恢復出明文 M0。攻擊方法是通過向服務器多次發送修改后的密文，分析響應是正確還是錯誤來確定修改結果，進而解密信息。如果收到正確，則表示是 0x00 02 開頭，那么 2B ＜ m ＜ 3B-1，且 B= 28(L-2)，而且基于 RSA 加密的延展性，可得 C=(C0 * Se) mod N=(M0 *S)e mod N，攻擊者可用 C 進行查詢，如果收到錯誤則增加 S，并重復上一步驟。攻擊者可以利用 0x00 02 大幅度減少可能的取值，2B ＜ M0*S- rN ＜ 3B，因此攻擊者能夠降低范圍 (2B+rN)/S ＜ M0 ＜ (3B+rN)/S，然后迭代選擇 S，進行Oracle 查詢，計算新的 r值，攻擊者便可以不斷縮小包含 M0 的范圍，不斷重復直到最后只剩唯一解。

但這個攻擊在被發現不久之后，研究人員便對錯誤信息做了統一，并且關閉了這個側信道，使得這個攻擊短期內得到了解決。針對這個改進，Klima，Pokorny 和 Rosa 對 Bleichenbacher攻擊做了改進，他們在優化中重新定義符合 PKCS 明文的可能區間值。根據 SSL/TLS 規范：

PreMasterSecret正好是 46 個字節

PreMasterSecret前綴有兩個版本字節

填充字節不等于00

符合明文 Mi的 PKCS 包含將填充與有效載荷數據分開的空字節。從而得知一些有效信息，填充內容已知，其中包含2類型字節，k-51 個填充字節，單個空字節作為分隔符，2 個字節的版本號和 46 個 PreMasterSecret字節。加密內容中不僅有PreMasterSecret的值，還應該存在版本號信息，攻擊者可以通過驗證構造的版本號的正確性達到查詢的目的。他們還進行了對之前的 Bleichenbacher 攻擊的防御措施進行破壞研究，如生成隨機預主密鑰。為應對握手信息的泄漏，設定直到對 Finished 消息的驗證和解密發現密鑰不同而中止會話。后來，Bleichenbacher 攻擊又被 Bardou，Focardi等人進行了改進，在 [5]中提出了相應的改進方法，使得攻擊執行得更快，而且大量減少查詢的次數，極大的增加了攻擊的效率。他們還結合他們的結果做出了分析，從結果來看是一個非常明顯的改進。

為了應對 Bleichenbacher 攻擊，從 RFC 2246（TLS 1.0）開始的所有 TLS RFC 建議“以與正確格式化的 RSA 塊不可區分的方式處理錯誤格式化的消息”。在 [6]中，作者展示了這個工作并沒有成功實現，提出了四個新的 Bleichenbacher側信道和三個成功的 Bleichenbacher攻擊針對 Java 安全套接字擴展（JSSE）SSL / TLS 實現和硬件安全家電使用 Cavium NITROX SSL 加速器芯片。作者成功驗證 Bleichenbacher攻擊還能夠成功的對 SSL ／TLS 協議進行攻擊，改善工作還需要繼續。

表2 PKCS#1 v1.5

DROWN 攻擊

Bleichenbacher 攻擊進一步升級，在 2016 年，利用 PKCS#1 v1.5 加密填充的遺留問題，結合 SSLv2 發起了對 SSL ／ TLS 近年來較為嚴重的一場攻擊。在 [7]中，DROWN(Decrypting RSA using Obsolete and Weakened eNcryption)攻擊威脅到了百萬級的服務器。SSLv2 雖然是退役的協議，但是還有大量的服務器支持該協議，沒有完全移出廢棄協議，從而導致嚴重的后果。利用該漏洞，觀察服務器的響應來解密的 RSA密文信息。并且利用這個這個漏洞，攻擊者可以在沒有RSA 密鑰私鑰的情況下，可以完成跨協議的攻擊，來解密 SSL 3 或者更高級的 TLS 會話。就算服務器本身不支持 SSLv2，但是與使用 SSLv2 的服務器共享 RSA密鑰，也會受到DROWN 攻擊的連鎖反應。

DROWN 攻擊區別于 Bleichenbacher攻擊是它利用 SSLv2 解密 ClientKeyExchange 信息。其中要利用 Bleichenbacher 的方法，必須解決兩個問題，首先是攻擊者需要吧 TLS密文轉換成有效的 SSLv2 密鑰交換信息，才能應用 Bleichenbacher 攻擊，然后是Oracle 查詢需要嚴格的檢測非填充部分的長度。

根據 Bardou 發表的論文，Bleichenbacher 攻擊需要大約百萬級以上的查詢次數。而DROWN攻擊則利用了一些特殊的攻擊技巧來提升攻擊效率，使用 Trimmer來剪切截獲的經過 RSA 加密的明文信息，然后精心構造 00|02|PS|00|密文消息的結構。然后利用 SSL 協議的出口協議來弱化會話密鑰，攻擊者將截斷會話密鑰至 5 字節。然后進行 Oracle 查詢，一旦成功查詢，便可以對成功篡改的密文做多次平移操作，從而對未知長明文消息做分段攻擊。最后將各個小段的解密信息組合起來，構成解密明文信息。作者還對 Bleichenbacher攻擊做出了新的改進，他們發現該旁信道仍存在可被利用的方式，如使用同一個剪切過的 RSA 密文對 Oracle 做兩次詢問。若剪切正確，在 Oracle 的兩次答復會使用正確的短會話密鑰返回結果，讓攻擊者通過成功驗證得知剪切是成功的。否則 Oracle-E 的兩次答復會使用兩個不同的隨機數偽裝“短會話密鑰”，通過仔細驗證收到的返回信息，攻擊者也能得知剪切是否成功。攻擊者還利用了 SSLv2 協議的漏洞中的一種“高效設計”，即允許客戶端通過明文指令要求服務器把高位 RSA加密的密鑰置零，攻擊者加以利用，甚至能達到將服務器的會話密鑰設置為只含有一個字節的信息量。

充分利用這些優化攻擊技巧，DROWN 攻擊能夠通過以下方式進行：收集大量的 TLS RSA 密鑰交換信息，大約 1000 個左右就可以進行解密。把截獲的含有 48 字節預主密鑰的 TLS 密文截斷成多個小段，然后組建成 RSA PKCS#1 v1.5 編碼格式。構造00|02|PS|00|小段密文結構，使用改進的 Bleichenbacher 攻擊，發起多個 SSLv2 Export_40 連接，并進行多次 Oracle 解密信息把解密的明文組建成原來的消息。

研究人員表示他們能夠通過 1000 個記錄的握手信息，40000個 SSLv2 連接和 250 次離線計算，在使用 2048 字節 RSA 密鑰的服務器中，解密 TLS1.2 握手信息，而且如果使用共享云資源，可以在 8 小時內完成攻擊，成本約 440 美元。他們還指出如果使用特殊的 DROWN 攻擊可以降低 SSLv2 連接到 14000 個。

攻擊威脅到了大量的用戶，能夠破解會話信息，如果被截獲的信息是銀行賬號或者國家機密信息，危害將不可估計，攻擊成本也不高，而且如果攻擊對象是普通用戶，解密過程將更簡單，速度更快，成本將更低。DROWN攻擊充分體現了使用最新協議，及時將廢棄協議完全停止的重要性，也顯示了密鑰重用帶來的重大危害，使用過時的加密協議和弱加密原語對會話造成的嚴重威脅。

很多加密方式在最初設計的時候，并沒有考慮太多的安全性問題。在實際的應用中，使用可靠加密原語和側信道強化的算法是很有必要的。側信道的大量信息泄漏給攻擊者提供了檢測的條件，使得攻擊者將這些條件作為修改密文后的測試結果。而服務器端返回的錯誤信息提示越多，攻擊者檢測就越便利。減少一些非必要的返回信息在服務器端是很有必要的，而側信道中泄漏的信息也需要盡可能的減少。SSL 雖然定義了相同的錯誤消息填充和解密，但是仍然不能避免時間側信道的攻擊。所以類似 CBC這樣的弱方案應該被重新審視，應該考慮使用更安全，更有效的加密方式。廢棄的協議一定要及時完全禁用，利用老版本協議，DROWN這種大規模的攻擊是具有很嚴重威脅性的，一些低版本的協議影響著新協議的安全性，所以推進 SSL 3 的完全禁用也是很有意義的。

RC4加密原理

RC4 是 Ron Rivest在 1987年設計的加密算法，作為一種較早出現仍被大量使用的高效加密算法。由于對CBC 模式的攻擊大量出現，加密方式的重心開始轉移到 RC4，使得 RC4開始廣泛的受到關注，也開始被大量研究人員重視。雖然早在 2001 年，RC4 就被 Fluhrer, Mantin 和 Shamir等研究人員證明其密鑰調度算法存在缺陷[8]。在分析大量的弱密鑰后，發現密鑰中的少量關鍵位置對影響大量初始狀態輸出位值具有不可忽略的概率作用。也就是說，如果利用某些位置的已知明文（如HTTP報頭固定值）破解密鑰流的一部分內容，可以被放大利用到破解其他流上的對應位置。理論突破到實際應用往往會存在著一段距離，而近幾年對 RC4的研究更加深入。研究人員們構造了一些能夠實際測量的攻擊，加速了 RC4在 TLS應用上的退役。

圖3 RC4 加密算法

RC4從設計之初到現在的應用一直非常廣泛，其原因在于加密方式簡單，效率非常高，在線上實時通訊加解密等方面起著至關重要的作用。如圖3所示，RC4的加密原理并不復雜，加密算法主要分成兩部分。第一部分是密鑰調度算法 (KSA) ，通過密鑰key 來初始化 S 狀態。第二部分是偽隨機數生成算法 (PRGA)，通過使用 KSA 初始化后的 S，生成偽隨機序列，更新 S，如圖4 所示（來源于 Google）。

AlFardan 等 在[9]中分析了 RC4 的安全性和近幾年來RC4出現的種種狀況，當RC4被用于TLS 加密時，作者設計了實驗對 TLS進行了純密文文本恢復攻擊。提供了兩種明文恢復攻擊方法，而且這些攻擊也可以實際應用于 RC4 加密的 TLS 會話中。其中主要根據 Mantin 和 Shamir等人在RC4流中發現的兩個偏差進行的設計。

圖4 RC4 加密

單字節偏差攻擊

RC4在密碼學中存在最重要的問題就是加密偏差問題。Mantin 等人通過統計分析，貝葉斯分析等方法發現密鑰流中的第二字節傾向于為 0 的概率比一般情況要高，為 1/128 而不是正常的 1/256。

如圖5所示，在S初始化結束生成密鑰流的過程中，最初，i和 j為 0。用 X 表示 S0 [1]，則在第一輪中將 i更新為 1，并將 j更新為 0 + S0 [1] = X，并且位置的內容 X 和 Y 也即 1 和 X 被交換。第一個輸出是 S1 [X + Y]，它可以是具有基本上均勻概率分布的任何值?，F在使用 S0 [2] = 0 的假設。在第二輪中，i被遞增到 2，并且 j增加到 X + 0 = X，因此我們交換位置 2 和 X 的值 0 和 X，并且輸出 S2 [X + 0] = S2 [X] = 0。以下證明，對于大約 1 / N 的密鑰，第二個輸出為 0，概率為 1，而對于其他的 1 - 1 / N 個密鑰，第二個輸出為 0，概率為 1 / N 均勻分布。結果，第二位置輸出為 0的總概率為：

這種類型的偏差在密碼學中是極其危險的，只要知道了RC4密鑰流中的第二字節傾向于0，那么就能夠知道經過加密的密文的第二字節。其他存在偏差的字節也是同樣的。如果要在 TLS 中進行攻擊，需要建立多個連接，獲取相同明文被多種不同密鑰加密的密文數據。觀察第二字節的值，如果出現頻率較高，那么這個值很可能就是明文內容中的相同值。

在 AlFardan 等人發表的論文 [9]中，其中一個攻擊通過分析244個 RC4 密鑰的密鑰流，發現在最開始的 256 個字節中都存在著多種偏差。他們通過改進算法，分別處理不同位置的多種偏差。最后的效果能夠達到在 232個數據樣本下，破解全部 256字節的內容能夠達到 100。而且在被攻擊字符存在已知部分的情況下，數據樣本的數量能減少到 228，遠低于應該存在的 2128的安全性。

在現實生活中，這種攻擊暫時還是很難實施的。因為最少需要收集 228個數據樣本，被動攻擊很難在合理的時間內符合要求。就算每秒進行一次連接，也需要8年左右的時間才能收集齊。所以只有進行主動攻擊，通過注入 JavaScript惡意腳本進行中間人攻擊。而且能破解的內容是前 256 字節，如果瀏覽器把有效內容放到 256 字節后，這個攻擊就很難得到有效的內容。

雙字節偏差

除了單字節偏差，在 RC4流中還發現了存在多字節偏差。與單字節偏移相反，大多數所識別的多字節偏移不是單一位置，而是以規則間隔周期性連續出現在加密流中。

在 AlFardan 等人發布的第二個攻擊中，展示了如何使用雙字節偏差來破解明文。利用雙字節進行攻擊時不需要大量不同的 RC4密鑰加密的樣本，在同一個連接上能夠獲取多個樣本，從而有效地減少了需要建立的連接數。而雙字節攻擊能夠在13*230 個數據樣本下，破解 16 字節的明文數據內容。為了使目標 cookie 處于 TLS 消息中的固定位置，作者在 HTTP 頭中添加了填充，這使得加密的 POST 請求達到 512 字節，這也產生了一些額外的開銷。按照每小時生成 600 萬個密文的速度進行實驗，需要大約 2000 小時來收集數據。這個攻擊構造產生了大量的網絡流量，在實際網絡中，這個攻擊暫時也不能構成威脅，但是證實了雙字節偏差確實可以被利用。

攻擊改進

在 [10]中，作者提出不變性弱點 (Invariance Weakness)，這是RC4加密中的存在的L形鍵模式。它一旦存在于 RC4鍵中，在整個初始化過程中會保持部分置換狀態。當由PRGA算法處理時，該完整部分包括置換的最低有效位，通過流的長前綴確定所稱偽隨機輸出流的最低有效位，如圖6所示。這些存在偏差的流字節與明文字節進行異或運算，導致從密文到明文的轉換存在著泄漏。這些模式通常發生在不同數量的 LSB(Least significant bits)， 單 個 LSB，2 個LSB，3 個 LSB 至 7 個LSB，分別導致不同類別的弱RC4密鑰。

圖5 RC4 加密中開始兩輪 S0[2]=0 而 S0[1] 0

SSL 協議在許多密碼套件中使用 RC4 進行加密。在握手協議中，為上游和下游通信生成 RC4加密密鑰。在記錄協議中，上游密鑰用于客戶端到服務器通信的加密，而下游密鑰用于服務器到客戶端通信的加密。重要的是要注意，加密是有狀態的，使用第一個密鑰流字節來加密第一個消息，后續的密鑰流字節用于加密下一個消息等?？紤]到不變性弱點僅在密鑰流的前 100 個字節中表示，它只能用于受保護的上游流量的前 100 個字節和受保護下游流量的前 100 個字節。假設每個方向上的第一個加密消息是SSL 握手完成消息（SSL 的典型使用中為 36 字節），則大約 64字節的秘密明文數據將被保留。上游密鑰流的前 36個字節用于加密 Finished 消息，下一個字節用于加密實際應用數據。

雖然對在TLS中 RC4加密方式進行了很多高調的攻擊，但是根據 Garman 等人在 2015 年的統計中，發現 RC4 加密還是占了約 30 的 TLS 流量比例[4]。Garman 等研究人員于 2015 年 3 月發布他們在 TLS 中對 RC4 的攻擊細節[4]，其中重點是恢復用戶密碼。通過應用貝葉斯分析方法將密碼的先驗信息和收集的密文結合，轉化為密碼的后驗概率。根據論文中的結果顯示，針對 RC4 的攻擊效果只會越做越好，目前能夠做到 226次加密用來恢復用戶密碼具有很好的成功率，比之前 234次的效果好很多。作者分析了不同參數條件對攻擊效果的影響，如使用先驗概率構造的成功率會顯著提高；隨著密碼長度的增加，攻擊的成功率顯著下降；允許大的密碼測試數量值能提高攻擊的成功率；而使用Base64 編碼方式，會增加密碼的長度，但是由于編碼會引入冗余，又會有利于攻擊，整體效果上是有利于攻擊。

Vanhoef 和 Piessens 也在 2015 年 7 月提出了進一步的改進，打破 Wi-Fi保護訪問時間密鑰完整性協議（WPA-TKIP），并針對 TLS協議設計實用的明文恢復攻擊。使用統計假設檢驗的方法，發現 RC4密鑰流中新的偏差，并揭示了初始密鑰流字節中的許多新偏差，以及幾個新的長期偏差。利用這些偏差，盡可能的減少返回的候選列表。作者還引入了一種生成大量相同數據包的方法來打破 WPA-TKIP，這些分組通過生成其明文候選列表來解密，并且使用冗余分組結構來修剪不良候選。從解密的數據包中可以得到 TKIP MIC 密鑰，能夠用于注入和解密數據包。作者通過在受害者的瀏覽器中運行惡意的 Javascript ，通過收集 9*227個左右的 HTTPS 加密后的請求，能夠將攻擊時間縮短到約 52 小時。其中每個請求都是具有相同密鑰加密后的密文，為了在75小時內完成攻擊，則需要在每秒內發出約 4450 個請求。雖然對比 AlFardan 設計的攻擊需要 2000 小時要小很多，但是在距離實際可用于現實攻擊還差一點。因為在短時間內發送如此大量的請求會很容易被服務器檢測出來，但是這個實驗結果確實將針對RC4的攻擊又向實際可行的邊緣推進了一大步。

圖6 Invariance Weakness

雖然目前對于在TLS中使用 RC4加密的攻擊還沒達到實際可被利用的程度，但是它的安全期限已經變得很短了，在理想的情況下還是能夠被破解的。從對RC4的攻擊發展來看，只要是存在漏洞的算法，在被長久的研究中，總是會被找到攻擊的方案的。并能夠被不停的改進，直至達到現實可用的程度。所以一般的加密方案都是有一定的存活年限的，需要不停地更新加密方式。因此推進 RC4 在 TLS 上的停用是非常有必要的。例如在[10]中，作者強烈地建議 Web 應用程序管理員應考慮在其應用程序的 TLS 配置中禁用 RC4；鼓勵 Web 瀏覽器在 TLS 配置中禁用 RC4。 當然，最好的方案是按照 RFC7525 的建議，使用 AES-GCM。但 AESGCM 只在 TLS1.2 版本才支持。因此，推進 TLS1.2 以及新版本協議 TLS1.3 的廣泛部署，才是長久之計。

（責編：楊潔）

（ 作者單位為清華大學）

1. S.Vaudenay. Security flaws induced by CBC padding, application to SSL, IPSEC, WTLS… . In EUROCRYPT, 2002

2. N. AlFardan and K. G. Paterson. Lucky thirteen: breaking the TLS and DTLS record protocols. In IEEE, 2013

3. B. M?ller, T. Duong, and K. Kotowicz. This POODLE Bites: Exploiting The SSL 3.0 Fallback. Google, Sep 2014

4. D. Wagner and B. Schneier. Analysis of the SSL 3 protocol. In USENIX, 1996

5. R. Bardou, R. Focardi, Y. Kawamoto. Efficient padding oracle attacks on cryptographic hardware. INRIA, 2012

6. C. Meyer, J. Somorovsky, E. Weiss. Revisting SSL/TLS implementations: New Bleichenbacher side channels and attacks. In USENIX, 2014

7. N. Aviram, S. Schinzel, J. Somorovsky. DROWN: Breaking TLS using SSLv2. USENIX, 2016

8. S. R. Fluhrer, I. Mantin and A. Shamir. Weaknesses in the key scheduling algorithm of RC4. In Cryptography, 2001

9. N. AlFardan, R. Holloway and D. J. Bernstein. On the security of RC4 in TLS. In USENIX, Aug, 2013

10. I. Mantin. Bar-Minzva attack: breaking SSL with 13-year old RC4 weakness. In Blackhat, 2015