許多SSL庫的開發人員正在為一個漏洞發布補丁，該漏洞可能被用來從加密通信中恢復明文信息，例如瀏覽器身份驗證cookie。

修補工作之前，發現了新的方法來攻擊SSL，TLS和DTLS實現，使用密碼塊鏈（CBC）模式加密。這些新的攻擊方法是由倫敦大學皇家霍洛韋學院的研究人員納赫姆·阿爾法丹和肯尼斯·G·帕特森開發的。

這些人周一發表了一篇研究論文和一個網站，詳細介紹了他們的新攻擊，他們稱之為“幸運十三”。他們已經與幾個TLS圖書館供應商以及IE TF（互聯網工程工作隊）的TLS工作組合作解決了這個問題。

HPE贊助的Brand Post

下一章資訊科技業的定義：資訊科技服務的現場運作

“作為服務”模式提供的是服務，而不是產品；靈活性而不是剛性；以及與業務結果相一致的成本。

傳輸層安全（T LS）協議及其前身SSL（Secure SocketsLayer）協議是HTTPS（HypertextTransfer Protocol Secure）的核心部分，是在Web上保護通信的主要方法。數據報傳輸層安全（D TL S）協議基于TLS，用于加密在UDP（用戶數據報協議）上通信的應用程序之間的連接。

研究人員在他們的網站上說：“OpenSSL、NSS、GnuTLS、yaSSL、PolarSSL、Opera和Bounty Castle正在準備補丁，以保護CBC模式下的TLS免受我們的攻擊?！?/p>

這一發現意味著，最終用戶在訪問沒有應用補丁的HTTPS網站時，理論上可能會受到黑客的攻擊。不過，安全專家表示，這種漏洞很難利用，因此可能沒有什么值得警惕的理由。

他們說：“攻擊來自TLS規范的缺陷，而不是特定實現中的bug。”攻擊適用于符合TLS1.1或1.2或DTLS1.0或1.2[兩種規范的最新版本]的所有TLS和DTLS實現。它們還適用于SSL3.0和TLS1.0的實現，其中包含了對以前的填充Oracle攻擊的反措施。不同的攻擊也可能適用于不符合要求的實現。

這意味著幾乎所有用于實現互聯網上一些最重要的安全協議的庫都可能容易受到Lucky13攻擊。

好消息是，在現實世界中成功地執行這些攻擊從TLS連接中解密數據是困難的，因為它們需要特定的服務器端和客戶端條件。例如，攻擊者需要非常接近目標服務器-在同一個局域網（LAN）上。

padingoracle攻擊已經有十多年的歷史了。它們涉及攻擊者在傳輸過程中捕獲加密記錄，改變其某些部分，將其提交給服務器，并監視服務器需要多長時間才能使解密嘗試失敗。通過適應他的修改和分析許多解密嘗試之間的時間差異，攻擊者最終可以通過字節恢復原始明文字節。

在TLS規范的1.2版本中，TLS設計人員試圖阻止這樣的攻擊，將時間變化降低到他們認為太低而無法開發的水平。然而，來自阿爾法丹和帕特森的幸運十三號研究表明，這一假設是不正確的，成功的填充甲骨文攻擊仍然是可能的。

馬里蘭州巴爾的摩約翰·霍普金斯大學密碼學家、研究教授馬修·格林星期一在博客上說：“新的Al Fardan和Paterson的研究結果表明，至少從相對較近的距離上可以分辨出由填充物無效所造成的微小的時間差異?！斑@在一定程度上是由于計算機硬件的進步：大多數新計算機現在都配備了易于訪問的CPU周期計數器。但這也要感謝一些巧妙的統計技術，這些技術使用許多樣本來平滑和克服網絡連接的抖動和噪音?！?/p>

除了接近目標服務器外，成功的Lucky13攻擊還需要大量----數百萬次----的嘗試，以便收集足夠的數據，對時間差異進行相關統計分析，克服可能干擾進程的網絡噪聲。

為了實現這一點，攻擊者需要一種方法來迫使受害者的瀏覽器進行非常多的HT TPS連接。這可以通過在受害者訪問的網站上放置一段流氓JavaScript代碼來實現。

針對解密的秘密明文需要在HTTP S流中有固定的位置。這一條件是通過身份驗證（會話）cookie來滿足的-由網站在瀏覽器中存儲的用于記住登錄用戶的隨機文本的小字符串。認證cookie可以讓攻擊者訪問其相應網站上的用戶帳戶，使其成為值得竊取的寶貴信息。

然而，潛在攻擊者要克服的最大障礙是TLS在每次解密嘗試失敗后殺死會話，因此會話需要與服務器重新協商。“TLS握手并不快，這種攻擊可能需要數萬（或數百萬?。┟總€[恢復的]字節的連接，”格林說?！八詫嶋H上TLS攻擊可能需要數天。換句話說，不要驚慌?！?/p>

另一方面，如果服務器未能解密一個記錄，因為它被改變了，DTLS不會殺死會話，這使得“幸運十三”攻擊與該協議不符。

阿爾法丹和帕特森說：“攻擊只能由一個堅定的攻擊者實施，他位于被攻擊的機器附近，能夠為攻擊產生足夠的會話?！薄皬倪@個意義上說，這些攻擊以目前的形式對TLS的普通用戶不構成重大危險。然而，這是一個真理，攻擊只有隨著時間的推移才會變得更好，我們無法預料我們的攻擊或全新的攻擊可能還會有什么改進。”

安全公司Qualys的工程總監伊萬·里斯蒂奇（Ivan Ristic）同意，幸運十三號攻擊對DTLS來說是實用的，但對TLS來說，它們目前的形式并不實用。不過，他周二通過電子郵件表示，從學術角度來看，這項研究意義重大。

Web服務器管理員可以選擇在其HTTPS實現中對不受這些類型攻擊影響的密碼套件進行優先排序。對許多人來說，唯一的選擇是RC4，這是一種可以追溯到1987年的流密碼。

Ristic說：“人們普遍不喜歡RC4，因為它有已知的缺陷（沒有一個適用于SSL/TLS），但我們還沒有看到TLS中使用的針對RC4的工作攻擊?！睆倪@個意義上說，盡管RC4并不理想，但它似乎比TLS1.0中現有的替代品更強。

TLS1.2支持AES-GCM（AES Galois計數器模式），這是一個更現代的密碼套件，也不容易受到這些類型的攻擊。然而，TLS1.2的總體采用率目前較低。

根據Qualys創建的SSL Pulse項目的數據，該項目旨在監測SSL/TLS在整個Web上的支持質量，在互聯網排名前17.7萬位的HTTPS網站中，只有11%的網站支持TLS1.2。

“我認為這一發現將是加快TLS1.2部署的又一個原因，”Ristic說。

這不是人們第一次建議在TLS中優先使用RC4來防止填充oracle攻擊。同樣的事情發生在兩年前，當時宣布了BEAST（瀏覽器利用SSL/TLS）攻擊。

Ristic說：“從最近的SSL Pulse結果（1月）來看，我們知道66.7%的服務器容易受到BEAST攻擊，這意味著它們不會優先使用RC4?！捌渲?，一小部分將支持TLS1.2，并可能優先考慮僅在此版本的協議中支持的非CBC套件。然而，由于支持TLS1.2的瀏覽器太少，我認為我們可以估計大約66%的服務器將談判CBC?！?/p>