文/韋俊琳

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

文/韋俊琳

學(xué)術(shù)專欄

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

目前，TLS 已經(jīng)作為一種工業(yè)標(biāo)準(zhǔn)大量應(yīng)用于網(wǎng)絡(luò)交易，信息交流中。例如 HTTPS就是使用 TLS協(xié)議進(jìn)行加密傳輸HTTP流量，旨在為HTTP客戶端（如瀏覽器）和Web服務(wù)器之間，創(chuàng)建一條安全的連接，用來(lái)保證數(shù)據(jù)傳輸?shù)乃矫苄院屯暾?。?dāng)客戶端和服務(wù)器都同意使用TLS協(xié)議時(shí)，他們會(huì)通過握手來(lái)建立安全連接，一個(gè)完整的 TLS 握手過程如圖1 所示。

隨著 TLS 的廣泛應(yīng)用，關(guān)于 TLS 安全的研究也越來(lái)越多，越來(lái)越深入。在這些針對(duì)TLS的安全研究中，發(fā)現(xiàn)了許多可以被利用的漏洞，這些基于 TLS 的問題大致可分為以下幾類。

TLS所采用的加密算法的漏洞。例如早期設(shè)計(jì)基于 CBC 模式的一系列加密方式，給現(xiàn)在帶來(lái)很多的問題，形成了一系列的漏洞。還有 RC4之類的弱加密算法，也帶來(lái)嚴(yán)重的漏洞。

TLS 版本兼容帶來(lái)的漏洞。由于過時(shí)的協(xié)議如 SSL3，不能及時(shí)退役，對(duì)新版本的協(xié)議也造成了很嚴(yán)重的影響。例如利用降級(jí)攻擊，讓通信雙方使用舊版本，從而攻擊雙方的會(huì)話，還有 DROWN 攻擊利用 SSLv2 協(xié)議對(duì)大量服務(wù)器進(jìn)行攻擊，造成很嚴(yán)重的影響。

TLS實(shí)現(xiàn)的漏洞。由于 TLS的開發(fā)人員，沒有嚴(yán)格按照TLS協(xié)議的標(biāo)準(zhǔn)規(guī)范來(lái)實(shí)現(xiàn)，或者程序本身實(shí)現(xiàn)有問題，導(dǎo)致了很多 TLS相關(guān)的漏洞。

TLS 所使用的數(shù)字證書的相關(guān)漏洞。證書管理和驗(yàn)證的復(fù)雜性，也導(dǎo)致了一系列針對(duì)證書的相關(guān)攻擊，偽造證書，過期證書的清除工作較難解決。

CBC加密模式

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

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

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

Lucky Thirteen 攻擊

圖2 CBC 模式加密解密

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

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

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

POODLE 攻擊

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

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

在進(jìn)行 POODLE 攻擊時(shí)，攻擊者能夠截獲密文，正常情況下，直接修改填充字節(jié)的內(nèi)容的方法是不可行的，因?yàn)槿绻淖兞薓AC值時(shí)會(huì)引發(fā)錯(cuò)誤，只有當(dāng)最后整個(gè)塊都是填充數(shù)據(jù)時(shí)，攻擊者才能夠可以進(jìn)行自由的修改并且不會(huì)導(dǎo)致MAC校驗(yàn)的失敗。正常情況下，攻擊者盡管對(duì)密文只做了一位修改，也會(huì)導(dǎo)致密文解密發(fā)生大量的變化，而且解密后的內(nèi)容也會(huì)變成隨機(jī)內(nèi)容。實(shí)際上，SSL 3 在做解密校驗(yàn)時(shí)，只需最后的填充長(zhǎng)度字節(jié)是正確的。在每次攻擊嘗試時(shí)，攻擊者將需要解密的塊移至最后一塊，然后修改倒數(shù)第二塊的最后一個(gè)字節(jié)進(jìn)行查詢，一直重復(fù)修改直到服務(wù)器成功接收修改后的內(nèi)容。攻擊的主要思路是攻擊者針對(duì)較大的的URL和較小的請(qǐng)求體，通過縮短URL，每次一個(gè)字節(jié)，直到找到正確填充長(zhǎng)度。通過提交足夠多次的修改來(lái)破解一個(gè)字節(jié)，最后同步修改URL內(nèi)容和請(qǐng)求體的大小并循環(huán)破解剩余部分。攻擊的主要原理是數(shù)據(jù)塊最后一個(gè)字節(jié)解密后的值為 15（假設(shè)塊大小為 16）

表1 瀏覽器自動(dòng)降級(jí)

面對(duì)這個(gè)嚴(yán)重的漏洞，Chrome 和 Firefox 等瀏覽器都禁止回退到 SSL3，IETF 也出臺(tái)相應(yīng)的方案來(lái)應(yīng)對(duì) POODLE 攻擊。根據(jù)標(biāo)準(zhǔn)化的防降級(jí)方法，瀏覽器可以采用一個(gè)特殊的信號(hào)套件 TLS_FALLBACK_SCSV 信號(hào)，當(dāng)信號(hào)值改變時(shí)，瀏覽器能夠通知服務(wù)器自己被降級(jí)了。這個(gè)方案不僅是為了解決 SSL 3 的POODLE 攻擊，而且是為了長(zhǎng)期解決降級(jí)攻擊問題提出的增添防降級(jí)信號(hào)。這個(gè)攻擊的出現(xiàn)實(shí)際上大幅度推進(jìn)了 SSL 3 的禁用，促使服務(wù)器采用更安全的協(xié)議，使用更安全的加密方式。

Bleichenbacher 攻擊

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

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

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

但這個(gè)攻擊在被發(fā)現(xiàn)不久之后，研究人員便對(duì)錯(cuò)誤信息做了統(tǒng)一，并且關(guān)閉了這個(gè)側(cè)信道，使得這個(gè)攻擊短期內(nèi)得到了解決。針對(duì)這個(gè)改進(jìn)，Klima，Pokorny 和 Rosa 對(duì) Bleichenbacher攻擊做了改進(jìn)，他們?cè)趦?yōu)化中重新定義符合 PKCS 明文的可能區(qū)間值。根據(jù) SSL/TLS 規(guī)范：

PreMasterSecret正好是 46 個(gè)字節(jié)

PreMasterSecret前綴有兩個(gè)版本字節(jié)

填充字節(jié)不等于00

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

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

表2 PKCS#1 v1.5

DROWN 攻擊

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

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

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

充分利用這些優(yōu)化攻擊技巧，DROWN 攻擊能夠通過以下方式進(jìn)行：收集大量的 TLS RSA 密鑰交換信息，大約 1000 個(gè)左右就可以進(jìn)行解密。把截獲的含有 48 字節(jié)預(yù)主密鑰的 TLS 密文截?cái)喑啥鄠€(gè)小段，然后組建成 RSA PKCS#1 v1.5 編碼格式。構(gòu)造00|02|PS|00|小段密文結(jié)構(gòu)，使用改進(jìn)的 Bleichenbacher 攻擊，發(fā)起多個(gè) SSLv2 Export_40 連接，并進(jìn)行多次 Oracle 解密信息把解密的明文組建成原來(lái)的消息。

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

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

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

RC4加密原理

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

圖3 RC4 加密算法

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

AlFardan 等 在[9]中分析了 RC4 的安全性和近幾年來(lái)RC4出現(xiàn)的種種狀況，當(dāng)RC4被用于TLS 加密時(shí)，作者設(shè)計(jì)了實(shí)驗(yàn)對(duì) TLS進(jìn)行了純密文文本恢復(fù)攻擊。提供了兩種明文恢復(fù)攻擊方法，而且這些攻擊也可以實(shí)際應(yīng)用于 RC4 加密的 TLS 會(huì)話中。其中主要根據(jù) Mantin 和 Shamir等人在RC4流中發(fā)現(xiàn)的兩個(gè)偏差進(jìn)行的設(shè)計(jì)。

圖4 RC4 加密

單字節(jié)偏差攻擊

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

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

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

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

在現(xiàn)實(shí)生活中，這種攻擊暫時(shí)還是很難實(shí)施的。因?yàn)樽钌傩枰占?228個(gè)數(shù)據(jù)樣本，被動(dòng)攻擊很難在合理的時(shí)間內(nèi)符合要求。就算每秒進(jìn)行一次連接，也需要8年左右的時(shí)間才能收集齊。所以只有進(jìn)行主動(dòng)攻擊，通過注入 JavaScript惡意腳本進(jìn)行中間人攻擊。而且能破解的內(nèi)容是前 256 字節(jié)，如果瀏覽器把有效內(nèi)容放到 256 字節(jié)后，這個(gè)攻擊就很難得到有效的內(nèi)容。

雙字節(jié)偏差

除了單字節(jié)偏差，在 RC4流中還發(fā)現(xiàn)了存在多字節(jié)偏差。與單字節(jié)偏移相反，大多數(shù)所識(shí)別的多字節(jié)偏移不是單一位置，而是以規(guī)則間隔周期性連續(xù)出現(xiàn)在加密流中。

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

攻擊改進(jìn)

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

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

SSL 協(xié)議在許多密碼套件中使用 RC4 進(jìn)行加密。在握手協(xié)議中，為上游和下游通信生成 RC4加密密鑰。在記錄協(xié)議中，上游密鑰用于客戶端到服務(wù)器通信的加密，而下游密鑰用于服務(wù)器到客戶端通信的加密。重要的是要注意，加密是有狀態(tài)的，使用第一個(gè)密鑰流字節(jié)來(lái)加密第一個(gè)消息，后續(xù)的密鑰流字節(jié)用于加密下一個(gè)消息等。考慮到不變性弱點(diǎn)僅在密鑰流的前 100 個(gè)字節(jié)中表示，它只能用于受保護(hù)的上游流量的前 100 個(gè)字節(jié)和受保護(hù)下游流量的前 100 個(gè)字節(jié)。假設(shè)每個(gè)方向上的第一個(gè)加密消息是SSL 握手完成消息（SSL 的典型使用中為 36 字節(jié)），則大約 64字節(jié)的秘密明文數(shù)據(jù)將被保留。上游密鑰流的前 36個(gè)字節(jié)用于加密 Finished 消息，下一個(gè)字節(jié)用于加密實(shí)際應(yīng)用數(shù)據(jù)。

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

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

圖6 Invariance Weakness

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

（責(zé)編：楊潔）

（ 作者單位為清華大學(xué)）

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