漏洞編號：CVE-2016-0800
漏洞介紹：https://drownattack.com/技術分析：https://drownattack.com/drown-attack-paper.pdf圖靈獎在同一天剛頒發給了 Diffie 和 Hellman，HTTPS 就出了這麼個漏洞，真是太巧了。
對比上一次的 Heartbleed 漏洞，這個漏洞的影響範圍似乎更大，破壞性更為嚴重。
攻擊者首先通過中間人攻擊獲得 TLS 數據，然後利用 SSLv2 漏洞挖掘出數據的明文信息。根據官網的數據，超過 30% 的網站使用的 HTTPS 都將受到該漏洞的威脅。
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。作者：鍊石網路CG鏈接：DROWN—TLS-SSLv2跨協議攻擊分析 - 知乎專欄來源：知乎給大家分享兩篇原創專欄文章：
DROWN—TLS-SSLv2跨協議攻擊分析 - 知乎專欄針對DROWN溺水攻擊的緊急修正說明 - 知乎專欄第一篇直接貼過來，請各位指正：
引言 波及範圍廣泛的DROWN溺水攻擊，在一出現時便引起了人們的廣泛關注。之前人們認為「堅不可摧」的TLS流量是如何被DROWN攻擊解密？TLS/SSL協議的實現應該採用什麼樣的演算法標準？考慮到攻擊環境要求與攻擊成本之後，這樣的漏洞能否真正構成威脅？在這樣一個互聯網被大規模監控，加密流量被隨意抓取留存的「後稜鏡時代」，對於DROWN攻擊我們應如何應對？關於這些問題，本文將給出你想要的答案。摘要 2016年3月DROWN漏洞發布，利用過時的、弱化的一種RSA加密演算法來解密破解TLS協議中被該演算法加密的會話密鑰。DROWN漏洞也許不如Heartbleed漏洞的影響範圍廣，但從攻擊模式看DROWN可以被動收集加密信息、並在之後再展開在線攻擊，也即DROWN可以攻擊離線的加密信息，因此DROWN可以解密之前被認為堅不可破的TLS流量，DROWN的影響和潛在威脅其實遠超出預想。作為鍊石網路CGLab社區計劃的一部分，本文用適宜於一般技術人員的形象化語言，還原了TLS密碼學流程的關鍵點，揭露了DROWN攻擊背後的本質技術原理。
然而本文更重要的任務是通過對DROWN攻擊的原理性解釋明晰化我們的一個觀察：迄今為止對於TLS協議已經發現了多種攻擊，但很不幸協議的修改多採用了貌似巧妙的、然而實質上卻為頭痛醫頭、腳痛醫腳的修改技巧，致使協議漏洞的修理一直處於治標不治本的狀態。具體的講，在DROWN攻擊適用的TLS協議自1998年至今的各種修改版本中，攻擊之所以能得逞的本質原因就是TLS協議的RSA加密演算法一直採用了一個無法提供密文完整保護的過期標準。 進一步作為本文的獨立觀點我們指出：TLS/SSL協議RSA加密演算法的治本性解決方案是採用RSA Optimal Asymmetric Encryption Padding（OAEP）標準。RSA-OAEP不僅是一個可嚴格證明安全的RSA加密演算法標準，而且OpenSSL代碼庫已經提供了該標準演算法的代碼實現，因此我們建議的治本性修改也是簡便實際可行的。最後我們有必要指出：TLS/SSL協議的工程實現存在著諸多非完美之處，這已不僅是不爭之史實，還是必須接受之現實，制定加密演算法標準的一個重要作用就是在非完美的現實世界中利用密碼學方法獲得敵無我有之優勢，我們應當避免在協議工程實現上與攻擊者陷入無優勢的技巧較量。作者介紹：鍊石網路CGLab（CipherGateway Lab）成立於2015年，是一個信息安全實驗室，側重密碼技術在雲計算領域的工程化應用，研究範圍包括雲計算場景下的新密碼演算法及協議的安全分析和應用，也涉及傳統密碼工程化中的漏洞發現、利用、安全防禦。轉載本文請與作者聯繫確認：CGLab@ciphergateway.com。 DROWN漏洞公開後引起了業界的廣泛關注，我們意識到DROWN和CipherGateway要提供給客戶的價值有關，於是鍊石網路CGLab發起了針對DROWN的分析工作小組，並有幸邀請到了對密碼學和密碼工程有豐富經驗和深厚功底的毛文波博士和Joe，一起參與到研究分析工作中，在此特別感謝。
一、概述
2016年3月伊始，一組安全研究人員發布了針對TLS的新漏洞攻擊——DROWN（Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800），也即利用過時的、弱化的一種RSA加密演算法來解密破解TLS協議中被該演算法加密的會話密鑰。 具體說來，DROWN漏洞可以利用過時的SSLv2協議來解密與之共享相同RSA私鑰的TLS協議所保護的流量。研究報告的數據顯示，僅在HTTPS協議方面，全球範圍內三分之一的HTTPS伺服器受到波及，具體的量級在1100萬左右，其中包括諸多知名的大型網站。 DROWN攻擊依賴於SSLv2協議的設計缺陷以及知名的Bleichenbacher攻擊（後文將描述）。 從一個小故事開始： Alice通過快遞給她的商業夥伴Bob郵寄了幾頁文件，而他們的競爭對手Eve買通了快遞員拿到了快遞，打開後發現文件上的內容都是奇怪的字元，應該是被加密了，而且據說這套加密體系是由全世界最聰明的人們設計的，如果沒有Bob手上的密碼本根本無法解密，所以Eve只能無奈地複印這一頁頁看不懂的字元，然後把文件交還給快遞員。突然有一天，Eve發現Bob有一個弱點，原來Bob和他的年幼的弟弟Bunny生活在一起，Bunny可以看到Bob的密碼本... 於是，Eve就開始往Bob家打電話，一遍遍地把Alice發給Bob的文件中的內容摘取並修改後編成問題向Bunny詢問，而天真的Bunny覺得反正Eve沒有直接要密碼本，應該不是壞人，就不厭其煩地用哥哥Bob的密碼本來解讀Eve的問題，並將直接告訴Eve結果... 通過一次次地欺騙Bunny，Eve解密了Alice發給Bob的商業秘密，可以開展她的惡意競爭行動了...
二、SSLv2 在TCP/IP協議族內實現安全通信一直是密碼與網路協議研究人員努力的目標，而TLS是這一努力過程的最為重要的成果之一，並被廣泛應用於安全瀏覽、郵件保護等應用之中。 TLS的誕生也是一個逐漸演變的過程，其前身是由NetScape公司所設計的SSL（Secure Sockets Layer）協議，第一個公開發表的版本為SSLv2。SSLv2發表於1995年2月，當時的人們還不知道如何設計安全協議，也由於當時美國政府對密碼出口的管制條例使得SSLv2的設計者不得不採用弱化的加密演算法。雖然SSLv2發表一年之後即被SSLv3所替代，並且2011年的RFC 6176中正式禁止了SSLv2的使用，但是由於伺服器端的配置不當以及廣泛部署的OpenSSL中的CVE-2015-3197漏洞，使得直到今天支持SSLv2的伺服器（甚至可以使用export密碼演算法）仍廣泛存在：17%的HTTPS伺服器、28%的SMTP伺服器等仍然支持SSLv2的使用（數據來源於參考資料1）。伺服器端廣泛存在的對SSLv2協議的支持是DROWN攻擊的影響範圍甚廣的主要原因。
三、密碼協議須判斷協議消息的完整性
密碼學業界早已達成共識：使用一個被篡改過的密文所解密出的明文是非常危險的，因為攻擊者可以通過對密文進行精心篡改，以控制接收者解密出的明文，從而達到欺騙接收者的目的。這裡用著名的RSA加密演算法舉個栗子，首先RSA原始加密演算法為:
其中(e, N) 是收信方Bob的公鑰，m是發信方Alice要發給Bob的明文消息，為保護明文m的私密性，Alice用Bob的公鑰通過原始RSA演算法將m轉換為密文c，只有Bob可以用私鑰將密文c加密還原成明文m。原始RSA加密演算法的密文可被隨意篡改而解密方Bob無法知曉是否被篡改，比如Eve想對m除以10，她可先截獲c，計算
然後c"=s * c mod N 發給Bob,由於
，所以Bob解密後得到的明文將不是m，而是m除以10，顯然原始RSA加密演算法無法讓解密方知曉密文是否被篡改過。 因此必須在安全協議通信中對所傳輸的密文實施符合密碼學嚴格程度的數據完整性保護，確保接收者能夠清晰判斷解密所獲得的明文是否來自於被篡改的密文，從而讓接收者能夠丟棄那些有問題的解密明文。密碼學完整性保護有多種方法，SSLv2協議中的RSA加密演算法採用了PKCS#1 v1.5規定的明文padding格式，該格式試圖讓參與協議的伺服器根據RSA解密後明文中某些規定位元組的內容判斷密文是否具有完整性。PKCS#1 v1.5規定加密時要對明文頭部添加一些完整性校驗位元組，如下：
這個公式中00|02|PS|00就是完整性校驗字元串，其中PS=Padding String，不含有00。若解密後看到的消息帶有這樣的完整性校驗字元串，則判定密文c未被篡改過，後綴的m也就是有效明文消息，否則判定密文被篡改過，解密結果是無效的應予丟棄。這是一個很簡單的密文「完整性」（明文「有效性」）判定方法。可惜正如我們打引號所表明，RSA PKCS#1 v1.5 padding完整性檢驗方法過於簡單粗糙因而其得出的密文完整性判定本身就是無效的：顯然，一個被篡改過的RSA密文仍然存在某個不可忽略的概率使明文呈現如此格式的位元組內容與順序，因而造成了密文完整性判定錯誤。在CRYPTO"98會議中Daniel Bleichenbacher正是利用了PKCS#1 v1.5的無效判定給出了一種針對這種加密體制的適應性選擇密文攻擊（Adaptive Chosen Ciphertext Attack，簡稱CCA2攻擊）：利用Bleichenbacher攻擊，攻擊者可利用協議在線伺服器的錯誤判定使之上當，向伺服器提交大量偽造密文，令其不停對攻擊者的偽造密文做出答覆，在二者大量交互過程中伺服器幫助攻擊者獲得解密消息。上當而不斷答覆攻擊者詢問的在線伺服器叫做oracle（源於古埃及、希臘神話故事中替神做出的難解答覆）。Bleichenbacher攻擊屬於一種旁信道攻擊，攻擊者要向oracle（以下我們管Bleichenbacher攻擊中的目標伺服器叫做Oracle-B）伺服器提交百萬量級的偽造密文詢問，每次從Oracle-B得到1比特信息量的Yes、No答覆，攻擊者從伺服器大量答覆中通過複雜的計算逐漸逼近正確的解密明文。自發現Bleichenbacher旁信道攻擊後SSL協議做了修改：若伺服器判定密文無效則生成一段隨機數答覆攻擊者，令攻擊者無法判斷其偽造的密文是否符合PKCS#1v1.5格式，從而無法獲得旁信道信息。然而很遺憾，旁信道信息泄漏並非Bleichenbacher攻擊的本質問題，本質問題是PKCS#1 v1.5密文完整性判定方法的無效性，取消旁信道屬於一種頭痛醫頭、腳痛醫腳、治標不治本的修改方法，新發現的DROWN攻擊還是可利用取消旁信道修改後協議仍然含有的漏洞。鍊石網路CGLab將於本文結論中討論一個治本的修改方法。
四、DROWN攻擊技巧工具箱工具1：Trimmer：剪切截短RSA加密的明文消息 RSA PKCS#1 v1.5 加密機制的一個特性允許攻擊者對密文做出十分精心的篡改，我們前面介紹過PKCS#1 v1.5所規定的「正確解密」構造為「00|02|PS|00|有效明文消息」。然而在一定概率下Eve仍然可以通過篡改密文讓Oracle（註：即開頭小故事中接收者Bob的年幼弟弟Bunny）的解密輸入具有這種構造，結果使Oracle對密文的完整性做出誤判，錯誤認定密文符合PKCS#1 v1.5格式，導致Oracle上當將已被篡改過的密文解密為明文消息，即PKCS#1 v1.5格式中第二個00的後續位元組，解釋為「有效」的解密消息。 Trimmer篡改的目的是將「有效明文」剪切截短。我們可對這個剪切明文工具的工作原理做一通俗性描述：RSA演算法加密的明文消息是一個整數，當該明文消息可被另一「剪刀整數」整除時（當然在一給定概率下），明文消息就被剪切截短了，比如35可被7整除，將35剪切截短為5。攻擊者可先對「剪刀整數」做RSA演算法加密，所謂精心篡改RSA密文就是用攻擊目標RSA密文除以RSA加密過的「剪刀整數」，結果等效於將「剪刀」伸入RSA加密演算法，使明文消息被「剪刀整數」整除，達到明文消息被剪切截短的效果。
進一步利用下面工具2，剪切截短明文消息（實為協議規定的會話密鑰）可令被剪切的明文消息短至僅含40比特（=5位元組）！SSL規定協議雙方用共享會話密鑰加密一個客戶端選取的、通過明文發送給伺服器的隨機數，作為驗證協議雙方握手正確性的驗證碼。如此短的共享會話密鑰可令攻擊者通過簡單暴力搜索方法從驗證碼搜索出會話密鑰！
工具2：SSL協議Export（可從美國出口）版：會話密鑰的弱化 1990年代美國政府通過法令強制限制若干密碼演算法所用密鑰長度在美國以外使用必須弱化為短密鑰，其中對SSL協議中會話密鑰的長度規定為不長於40比特（=5位元組）。該限制法令於2000年被放棄，然而很不幸其造成的密鑰弱化在應用中的生命周期遠遠跨越了法令實施的期限：時至今日仍有大量SSL伺服器還在遵從這個過期的出口限制法令。 既然作為一個client-server協議，SSLv2協議允許client通過和server交互討論（注意：client-server間的交互討論是以明文進行的），使雙方就所用的加密演算法、密鑰長度等選取達成一致認同。體現在對會話密鑰長度的認同上，SSLv2協議允許client通過明文指令要求server對會話密鑰的高位若干位元組置零，用此方法可將會話密鑰截短至出口限制所規定的長度：40比特。當oracle server判定解密格式符合PKCS#1 v1.5規定時，則同意client提出的會話密鑰截短指令。 工具2的運用也將SSLv2在線伺服器當做一個oracle，讓我們管這個oracle叫做Oracle-E（E = export），攻擊者Eve對一個偷聽記錄在案的TLS協議密文c——其中加密的明文是長會話密鑰，密鑰長度超過出口法令規定的40比特——先用工具1 Trimmer對c做剪切篡改成c』，Eve希望將c』 是一個具有SSLv2格式的出口版RSA密文，其中加密的明文是一個僅有40比特長度符合出口法令規定的短會話密鑰。剪切是否成功呢？這就要讓Oracle-E來回答了，Eve將c』發給配有符合出口限制規定的SSLv2在線伺服器（Bunny），通過明文指令：「Bunny：我要和你協商的會話密鑰是符合出口長度的40比特」。在一定的概率下Eve的剪切會成功，讓SSLv2伺服器上當而使用40比特長度會話密鑰與「客戶端」（實為攻擊者Eve）進行SSL協議的握手步驟，在握手步驟中Bunny會用40比特（=5位元組）短會話密鑰製作協議握手驗證消息，Eve可通過線下窮舉搜索的簡單方法將40比特短會話密鑰從握手驗證消息中暴力破解出來，線下搜索次數為2^40，在當下這是一個完全實際可行的計算成本。
工具3：Shift平移旋轉RSA明文消息，對未知長明文消息分段而攻之
我們已知RSA PKCS#1 v1.5密文完整性判定方法允許攻擊者利用工具1、2獲得SSLv2密文中最低位5位元組，即第二個00位元組後續部分被伺服器判定為「正確」明文消息，也就是一個被截短至5位元組的會話密鑰。一旦獲得了此低位5位元組已知短消息，攻擊者可對成功篡改的密文繼續做多次逐段「明文平移」篡改，逐段將密文中加密的高位未知位元組平移到低位，同時期望被平移篡改後的RSA密文仍然可被PKCS#1 v1.5判定方法認定為滿足SSLv2 export格式。平移技巧之所以工作，仍然多虧PKCS#1 v1.5粗糙判定方法在一定的概率基礎上可將一個「有效」密文精心篡改為另一新的「有效」明文。我們前面介紹RSA加密演算法是「指數 mod N運算」，指數運算的基本構造其實就是乘法，而乘法mod N運算構成了一個叫做「乘法有限環」的代數構造，在這個有限環中任意兩個數的相乘（除）mod N結果都仍然小於N，因而仍然是該有限環中的元素，也即該有限環對乘除運算是封閉的，前面我們已經看到：對RSA演算法加密的密文做乘法（即密文乘以一個數）等價於對明文做乘法（即明文乘以另一個相關的數，所謂相關就是密文為明文的e次方）。與工具1剪切技巧類似，平移篡改也是對RSA密文乘以一個精心挑選的平移乘數，所不同的是：平移是為了造成攻擊目標密文中的高位未知明文位元組向右方低位平移，而最低位的右方若干已知位元組會平移至最高位若干位元組，所以平移也對RSA明文造成旋轉。平移旋轉的平移乘數按所需平移比特位數決定，若需平移旋轉40比特，則平移乘數為：
有讀者或許會想到這個平移乘數的明文，1/(2^40)是個分數（帶小數點），不必擔心，在RSA乘法有限環代數構造下這個分數其實是一個小於N的整數。還有讀者或許還要問：這樣平移不會破壞PKCS#1 v1.5的有效明文格式嗎？是的，在一個不小的概率上會造成破壞，然而Eve的平移攻擊還可對密文再乘以：
其中s是一個精心選定的隨機數，這個隨機數s有兩個作用：（1）在一定概率下s可將PKCS#1 v1.5格式明文保持格式篡改成新的PKCS#1 v1.5格式明文，（2）在下面的工具4中，Eve可通過多次修改s值的方法，通過一個複雜的數學變換逐步逼近解密一個TLS長會話密鑰。在保持格式的概率上，平移旋轉高於剪切技巧。 反覆利用平移旋轉技巧，配合運用工具4，攻擊者可將TLS（注意，不再限於SSLv2協議）密文中的長會話密鑰解析獲得！平移旋轉篡改密文仍然需要一個SSLv2伺服器充當oracle，讓我們管這個oracle叫做Oracle-S（S = shift）。
工具4：改進過的Bleichenbacher旁信道攻擊：旁信道仍然存在 我們前面對Bleichenbacher旁信道攻擊做了介紹，攻擊者利用Oracle-B（B = Bleichenbacher）提供的旁信道信息可構造一種逼近技巧，逐步推導出真正的會話密鑰。 1998年後針對Bleichenbacher旁信道攻擊，業界對SSLv2協議做了修改：如果SSLv2伺服器收到的密文滿足PKCS#1 v1.5格式，則伺服器返回正常服務答覆，否則伺服器將返回一個用隨機數充當「會話密鑰」的偽裝答覆。由於攻擊者試圖利用的旁信道逼近技巧無法分辨此兩種答覆，Bleichenbacher旁信道攻擊似乎就不再可被攻擊者利用了。然而DROWN攻擊者發現旁信道仍然存在：用同一個剪切過的RSA密文對Oracle-E做兩次詢問，若剪切正確（剪刀整除成立），在Oracle-E的兩次答覆會用正確的短會話密鑰製作驗證碼，讓攻擊者通過成功驗證得知剪切是成功的，否則Oracle-E的兩次答覆會分別用兩個獨立隨機數偽裝「短會話密鑰」，讓攻擊者通過失敗驗證得知剪切不成功。這就讓DROWN攻擊得逞了：攻擊者通過兩次連線伺服器的成功驗證便可獲得如下明確通知：恭喜你：（1）你仍然成功地利用我充當了Oracle-B（= 2*Oracle-E ），（2）你還成功找到了可用的TLS密文作為攻擊目標密文，因而可逐次利用工具3，即Oracle-S技巧，分段製作Oracle-B所需的篡改密文，最終從攻擊目標TLS密文中逐段解析出128比特（=16位元組）長會話密鑰！
工具5：一個SSLv2協議設計漏洞 SSLv2協議含有一種「高效」設計允許client通過明文指令要求SSLv2 server將RSA加密的會話密鑰高位部分的任意多個位元組置零，該操作居然可「高效」到如此極端程度：server會聽從client指令將會話密設置為僅含1位元組（=8比特）的信息量！該「高效」協議設計已於2016年1月被悄然無聲fix了，然而很可能大量SSLv2伺服器並未及時打補丁，所以相關的協議漏洞仍然處於熱服務狀態。 前面介紹的工具2，Oracle-E的使用是為了從一堆偷聽記錄在案的RSA密文中選中一個，該選中密文所加密的明文可被成功剪切至5位元組（=40比特）短會話密鑰。攻擊成功而選中的RSA密文可被叫做「目標密文」。為了判斷是否成功選對了目標密文，攻擊者需要實施40比特空間窮舉搜索，這是個不小的空間，搜索仍然需要相當的成本。而且成功選中目標密文後攻擊者也僅得到SSLv2中加密的40比特會話密鑰，用此40比特已知會話密鑰，攻擊者還須再使用工具3、4：Oracle-S, Oracle-B, 對選中的TLS密文恢復出長會話密鑰，每次Oracle-S調用的平移旋轉步長也被限制在40比特，攻擊效率較低。再者，攻擊目標SSLv2協議還局限於可出口版本。 工具5協議設計漏洞放寬了Oracle-E的上述限制，該設計漏洞允許攻擊者指令伺服器將Candidate候選密文c的未知長密鑰（k位元組）高位任意位元組置零，於是攻擊者可採用如下置零技巧：第一步：令伺服器將c中加密k位元組密鑰的高位k-1位元組置零，用伺服器的答覆中的握手驗證信息搜索出第k位元組未知秘密，與工具2，Oracle-E製作握手驗證消息用了5位元組（=40比特）會話密鑰情況不同，在工具5情況下伺服器製作的握手驗證消息所用的會話密鑰僅含有1位元組（=8比特）未知信息，搜索1位元組至多僅需256次解密操作（平均128次）！Eve可重複運用工具5：令伺服器將c（注意，同一個Candidate候選密文c）中加密的高位k-2位元組置零，再搜索1位元組秘密，…，如此用同樣的Candidate候選密文c玩k次，便可（1）判定c是否為正確目標密文，（2）解密k位元組長會話密鑰。攻擊計算成本為k*128（平均解密次數），遠遠低於Oracle-E所要求的2^40次解密驗證操作。 顯然工具5也是讓伺服器提供oracle服務，讓我們將該oracle記做Oracle-extra-clear。
五、DROWN跨協議攻擊介紹 配備了以上5個工具，DROWN攻擊就能得逞了。DROWN攻擊者瞄準的攻擊對象為兩種伺服器：TLS協議伺服器和SSLv2協議伺服器，這兩個伺服器共享使用同一個RSA公鑰證書，如此共享證書的伺服器結對「一幫一，一對紅」實踐還相當普遍。 攻擊者首先通過對TLS目標伺服器偷聽記錄大量的協議密文——DROWN研究人員的實驗用了1000個，由於TLS伺服器服務於眾多客戶端，而攻擊不必盯住某個客戶端作為攻擊對象，所以偷聽記錄TLS協議密文不是什麼難事，攻擊者可在較短時間內完成所需數量的密文記錄任務。
5.1 DROWN General
上圖是DROWN General的流程示意圖 首先攻擊者用工具1：Trimmer剪切所記錄的TLS密文，將剪切密文發給SSLv2伺服器期待提供工具2：Oracle-E服務。注意，每次Oracle-E詢問，Eve都需要做兩次連接SSLv2伺服器（見工具4介紹，Oracle-B = 2*Oracle-E），外加大約2^40空間中窮舉搜索以確認剪切攻擊是否正確。正確的剪切使攻擊者從偷聽記錄在案的諸多TLS密文中挑中正確的可進一步利用工具3：Oracle-S，Oracle-B工具的目標密文。 第二步：一旦挑中了目標密文滿足PKCS#1 v1.5格式，利用工具3：Oracle-S可在一個不可忽略的概率可能性上將目標密文篡改成仍然滿足PKCS#1 v1.5格式的新目標密文。 第三步：對於滿足格式的目標密文，Oracle-B將會正常提供正確服務，而不會偽裝提供假服務。正確的Oracle-B服務可讓攻擊者利用逼近技巧逐步解析出目標TLS密文中的長會話密鑰（如16位元組）！ 至此我們已經介紹了DROWN跨協議攻擊的General版。為了讓工具3有效利用Oracle-S，General DROWN攻擊者應該指令Oracle-E：短密鑰須有些許長度，比如40比特（=5位元組），如此每次Oracle-S、Oracle-B可泄漏TLS長會話密鑰128比特（=16位元組）中的40比特（=5位元組）信息量，而攻擊者的窮舉搜索空間大小也將囿於2的40次方量級。所以攻擊者對Oracle-E做出的明文指令應該是：「將SSLv2會話密鑰的高位11位元組置零，我要用5位元組會話密鑰！」。請注意：置零位元組少了，搜索空間將以指數速度增大，搜索計算量也將快速增大，反之置零位元組多了，Oracle-S可平移的量就變小，導致連接Oracle-B的次數增加，使攻擊成功率下降。General DROWN攻擊大致要把握好這麼個平衡點。 攻擊的主要計算資源成本：與Oracle-E的交互包含對一個40比特會話密鑰的窮舉搜索，這個搜索計算成本為2^40次嘗試對稱密鑰解密。一旦成功找到了正確的目標攻擊密文後，利用Oracle-S, Oracle-B的成功攻擊概率大大增加，計算成本遠低於2^40次嘗試對稱密鑰解密，所以我們可以認為尋找目標攻擊密文的成本為2^40。由於尋找範圍為1000個從客戶端偷聽記錄在案的TLS密文，所以攻擊的總計算成本為2^50 約等於1000 * 2^40。
5.2 DROWN Special
上圖是DROWN Special的流程示意圖 攻擊者用工具5：Oracle-extra-clear代替General中的工具2：Oracle-E，平均僅需k*128次解密驗證操作便可有千分之一可能收到Oracle-extra-clear的祝賀消息，恭喜你：（1）你成功地利用我充當了工具4：Oracle-B（= 2*Oracle_extra-clear），（2）你還成功找到了可用的TLS密文作為攻擊目標密文，因而可進一步逐次利用工具3：Oracle-S，製作Oracle-B所需的篡改密文，最終從攻擊目標TLS密文中解析出很長位元組的會話密鑰！其中要格外恭喜的是：（3）你現在使用Oracle-S平移旋轉RSA明文時可k位元組大步快跑，而不必受限於General版使用Oracle-E情況，Oracle-S僅可每步5位元組小步慢走了。
六、討論DROWN攻擊得逞的本質 如同RSA加密演算法一樣，TLS/SSL協議自問世以來就一直在遭受攻擊的過程中成長，每次當一種新的攻擊披露後，新的修改方案也就隨之出現。然而這部攻擊-修改歷史基本上就是一部頭痛醫頭、腳痛醫腳的歷史。比如Bleichenbacher攻擊讓人們理解了RSA PKCS#1 v1.5格式存在旁信道泄漏信息，於是修改方案也就是實實在在地在協議中取消Oracle-B旁信道：伺服器檢查解密結果符合格式則提供正常協議答覆，反之不符合格式也用一個隨機數假裝提供「正常」協議服務。 雖然Bleichenbacher攻擊披露了一個旁信道，該攻擊的本質，包括DROWN攻擊的本質，其實是RSA PKCS#1 v1.5格式無法讓伺服器真正判斷其解密的RSA密文是否已經被CCA2類型篡改過。RSA PKCS#1 v1.5 padding格式沒有改變「教科書版本RSA加密演算法的一個本質屬性：對密文做乘法（即密文乘以一個數）等價於對明文做乘法（即明文乘以另一個相關的數），攻擊者可以通過密文、明文乘法的相關性精心篡改RSA密文，從而可使加密的明文滿足攻擊所需的某種性質，同時還不讓解密伺服器發現精心炮製的篡改。我們介紹的工具中Trimmer, Oracle-E, Oracle-S, Oracle-B無一例外皆利用了這個密文-明文之間具有乘法相關的屬性，而且在不可忽略概率下伺服器無法判定解密是否有效！之前對TLS/SSL所暴露漏洞的多種修改手段中都未切中要害-從RSA密文有效性的判定解決問題，比如在取消Oracle-B旁信道的修改中，伺服器「檢查解密結果符合格式則提供正常協議答覆，檢查不符合也用一個隨機數假裝提供服務」，其實伺服器根本就無確切把握分辨自己究竟應該「正常」還是「假裝」，於是所謂「取消旁信道」修改只不過是試圖讓伺服器與攻擊者在協議技巧上做較量，可惜在十分複雜並很可能含有工程實現缺陷的協議交互中，無辜的伺服器與惡意而來的攻擊者在技巧較量糾纏中很容易處於劣勢地位！ 正確的協議漏洞修改當然應該基於伺服器在密碼學方面較攻擊者的顯著優勢！Bellare-Rogaway於1994年提出了RSA Optimal Asymmetric Encryption Padding（OAEP）padding格式，OAEP採用了對稱密碼學加密演算法中的Substitution-Permutation Network（SP-Network, 由Shannon提出）構造，SP-Network構造非常徹底地破壞了教科書版RSA加密演算法的密文、明文之間存在的乘法相關構造，伺服器可從解密結果明確做出判斷：解密的明文是出自於源頭的加密者，或者說加密者完全知曉明文（Plaintext Awareness），而非來自於一個CCA2攻擊者，這樣的攻擊者根本就不知道其篡改的密文所對應的明文。TLS/SSL協議若採用RSA-OAEP標準加密會話密鑰，則協議完全不必就會話密鑰的長度做任何特殊處理手段，事實上被加密的明文消息哪怕短至1比特，解密方也會有充分把握判定所解密消息的正確性，根據OAEP演算法若判定解密正確，則攻擊者無法知曉被加密的明文消息究竟是0或1，反之若判定解密無效，則伺服器可安全終止協議，使攻擊者無法從協議可能存在的非完美之處獲知任何有用的信息！RSA OAEP抵抗CCA2攻擊的安全性是可形式化證明的。可以證明：若採用RSA OAEP padding，所有利用乘法相關性的CCA2攻擊（包含所介紹的五種工具）技巧全部都將灰飛煙滅，哪怕不同伺服器Cross共享同一RSA公鑰證書！ 1998年10月修改版RSA PKCS#1 v2 padding就採用了OAEP padding，然而由於種種原因，TLS至今還在採用RSA PKCS#1 v1.5。我們很遺憾的面對一個無奈現實：過期協議與過期演算法長久存在於應用中，它們很難消失！They die hard! DROWN攻擊在本質上揭示了教科書版本密碼學的非安全性，同時也在一個非本質層面揭示了應用中的另一個無奈現實：過時的東西真的很難消失！Old things really die hard! 作為鍊石網路CGLab的獨立觀點，我們認為：TLS/SSL協議RSA加密演算法的治本性解決方案是採用RSA Optimal Asymmetric Encryption Padding（OAEP）標準。RSA-OAEP不僅是一個可嚴格證明安全的RSA加密演算法標準，而且OpenSSL代碼庫已經提供了該標準演算法的代碼實現，因此我們建議的治本性修改也是簡便實際可行的。（參考資料5，RSA_PKCS1_OAEP_PADDING） 從另一個角度看，社區的SSL/TLS部署最佳實踐能為項目安全設計提供很有價值的參考，重視並遵循社區最佳實踐在一定程度上可以降低潛在的風險。(參考資料4，http://Hardenedlinux.org社區翻譯) 最後我們有必要指出：TLS/SSL協議的工程實現存在著諸多非完美之處，這已不僅是不爭之史實，還是必須接受之現實，制定加密演算法標準的一個重要作用就是在非完美的現實世界中利用密碼學方法獲得敵無我有之優勢，我們應當避免在協議工程實現上與攻擊者陷入無優勢的技巧較量。七、DROWN攻擊的影響 DROWN攻擊剛出現時，由於其波及範圍之廣，甚至有媒體驚呼又一個Heartbleed漏洞出現。 驚愕之餘，人們發現雖然該漏洞受眾廣泛，但是其對攻擊環境的要求比較苛刻、攻擊成本較高，相比之前Heartbleed漏洞的簡單粗暴有效，只能說小巫見大巫。 於是有了關於該漏洞是否真正構成實際威脅的爭論，滿足各種要求之後，攻擊者才能夠解密1000條TLS連接中的1條，而這需要為計算資源花費440美元並且等待8個小時出結果以及與目標伺服器進行40000次的SSLv2連接，怎麼看都不嚴重。 對於這一點的回應，引用Matthew Green的話非常合適「你的銀行賬戶是否值440美元？也許不是。但別人的賬戶可能值這麼多」。
然而這並不是全部的故事，通過同時利用DROWN漏洞與以及之前版本的OpenSSL漏洞CVE-2016-0703，攻擊者可以在普通計算機上用不到1分鐘的時間內解密260條TLS連接中的1條（通過增加向伺服器的查詢次數，甚至可以恢復100條TLS連接中的1條）。 在這種複雜度範圍內的攻擊使得攻擊者在條件滿足的情況下可以實時展開中間人攻擊，直到現在（2016年3月24日）通過DROWN的網站仍然可以檢測到國內某知名網站仍然存在著這方面的漏洞。 DROWN漏洞的另一個重要之處在於它披露了SSLv2協議本身的一個缺陷，與具體的SSL/TLS協議實現無關。
DROWN漏洞也許不如Heartbleed漏洞的影響範圍廣，也比Heartbleed更難理解。但從攻擊模式看DROWN可以被動收集加密信息、並在之後再展開在線攻擊，DROWN攻擊並不要求在信息傳輸時展開在線攻擊，也即DROWN可以攻擊離線的加密信息，因此DROWN可以解密之前被認為堅不可破的TLS流量，DROWN的影響和潛在威脅其實遠超出預想。當討論威脅的時候，首先需要考慮的是可能遭受損失的信息資產價值有多大！或許你不會因為幾個網站帳號被盜而煩惱，或者你覺得反正網銀上沒多少餘額...但是，萬一被破解的那個TLS會話恰巧包含了企業高管通過Web Mail發送的一份價值億萬的商業秘密文件，或者正好是一個遠程運維管理員登錄SSL VPN所輸入的用戶名與口令...在「後稜鏡時代」，大規模互聯網監控已經不是天方夜譚，而對加密流量的抓取留存也早就不是陰謀論式的科幻傳言。在這樣的場景下出現了DROWN這樣的攻擊手段，那些曾經使用SSL/TLS的朋友們，假如您發送的信息價值不僅僅是一個網站帳號或者一個銀行賬戶，而是事關國家安全、企業利益和網路安全，那麼除了祈禱「我不是那１/1000」之外，更靠譜的措施是趕緊修補漏洞吧！ 【附錄一：參考資料】：1,DROWN: Breaking TLS using SSLv2, Nimrod Aviram1, Sebastian Schinzel2,..., https://drownattack.com/drown-attack-paper.pdf2,PKCS #1: RSA Encryption Version 1.5, RFC 2313 - PKCS #1: RSA Encryption Version 1.53,DROWN Attack4,SSL/TLS部署最佳實踐v1.45,OpenSSL【附錄二：鳴謝】：在此感謝多位專家學者和研究者的支持，也感謝HardenedLinux社區Shawn的反饋意見。【附錄三：微信原文鏈接】：
DROWN—TLS-SSLv2跨協議攻擊分析
簡單來說，這個攻擊幹了這麼件事：
紫禁城大門打不開，我大白天爬梯子翻牆進了999間房中的一間。至於我能拿多少東西走，取決於我進的是哪間。
========分割線====乾貨在下面，請自備茶水=============================
今天讀了關於DROWN的論文，地址：https://drownattack.com/drown-attack-paper.pdf
利益相關：我相信自己學校的NDS研究組的Jurai Somorovsky博士和Christof Paar 教授不會出太無聊的東西。
在評價這個攻擊之前，我覺得有必要多說明一下這個攻擊的大概流程：
照著4.2.2節畫了上面這個的攻擊流程。（手誤：PKS應該是PKCS）
步驟5包含進行Bleichenbach
攻擊場景中有兩個Server, 一個部署了TLS 1.2， 一個部署了SSL v2.0，兩個Server共用一個RSA公鑰/私鑰對。
攻擊者主要干這些事情：
1.第一輪在線搜集信息和利用server的應答（Online, not that expensive but ...）圖中的第1步，搜集要攻擊的TLS客戶端-伺服器會話。因為真正的秘密信息是在客戶端伺服器協商好會話密鑰（session key）之後傳輸的，所以有必要保存握手之後的會話密文。客戶端在與
TLS Server的
握手中，如果使用RSA，則pms信息會由客戶端使用伺服器的公鑰進行加密後傳輸，即傳輸內容為C=Enc(PK_s, pms)。其後所有的會話信息會由pms導出的會話密鑰進行加密。參考RSA做密鑰協商(密鑰交換)時，是否可以防範中間人攻擊？ - 知乎用戶的回答
由於SSL v2.0 Server也使用相同的RSA公鑰，那麼很明顯，如果不考慮padding, C也會是一個合法的、在與SSL Server的握手中可能出現的密文，同時，客戶端在TLS會話中使用的nonce r_c，也是在SSL 2.0中合法的。
至於為什麼需要1000個，是因為有大概1/1000級別的概率把C轉化為在下面可以用到的、符合條件的信息C』。
如果一個C不行，就換下一個。
SSL v2.0的圖，來自DROWN論文
上圖圖中可以看到，SSL 2.0， 在並不驗證用戶是否知道mk_secret的情況下，只要Server自己解密出來的mk_secret符合RSA PKCS#1 v1.5的格式，Server就會發出一個Server Verify。這個Verify的內容是 Enc『 (server_write_key, r_c)。
其中server_write_key = MD5(mk||"0"||r_c||r_s), 而r_c是client自己發送的nonce。
再說一遍，Server只檢查解密出來的mk_secret是否符合RSA PKCS#1 v1.5的格式
如果Server並未中斷握手或者報錯，則代表轉化後的C"對應的明文符合RSA PKCS#1 v1.5的格式。
明文中含有mk_secret。
2. 線下進行運算（Offline，expensive）
步驟4。在線上過程中，一旦發現Server能發回一個Server Verify，就知道了C", 而r_c、r_s是攻擊者知道的。因此，如果Enc』是一個比較弱的對稱演算法，比如RC2之類，可以暴力破解出mk_secret。暴破是很貴的。
3. 再次上線 (Online, expensive)
步驟5，利用Bleichenbach攻擊和從之前得到的mk_secret，完全破解C, 得到pms這是比較耗費資源的地方，需要很多次SSL v2連接。
4. 下線破解(Offline, inexpensive)
步驟6、7。有了pms，剩下的就沒什麼難度了。
評價：
不說別的，首先這個攻擊大大降低了破解會話的難度。比如TLS中，可以用pms產生256位的AES-256 key，暴破會話的難度是2^254左右即使面對2048位的RSA本身，攻擊難度也超過2^80.而使用DROWN就變成了 2^50+ 幾萬條SSL v2連接，直接從不可能變成了可能。
另根據作者描述，一旦存在這樣一對server和弱加密演算法, 則此流程獨立於任何TLS/SSL的具體實現，是一個針對協議/演算法弱點的攻擊。
強調一下，此general DROWN
是針對協議/演算法弱點的攻擊。只要滿足在SSL v2和TLS共用相同的RSA公/私鑰對，且使用較弱的加密演算法，則general DROWN的成功概率和攻擊成本跟協議用的是OpenSSL還是別的實現沒太大關係。還有就是，同時這麼部署兩台伺服器，除了不該對舊協議繼續支持，並不明顯違反安全設計的常識。這就是真正的cryptanalysis和protocol analysis需要發現的問題。
而一些具體實現上的漏洞，會使這個攻擊的危害性更大。
比如第五節（5 Special DROWN）提到的Special DROWN， 如果伺服器上部署的OpenSSL是2015年3月前的版本，則攻擊者甚至可以直接發動中間人攻擊。
此外， QUIC協議也會受到影響，如果server config可以隨便發的話。
回到一開始的簡答，由於1/1000這個概率的存在，對於普通用戶，無害/重大危害都有可能。但是如果是每天發動數十萬或者上億條消息的server對server的TLS連接，則1/1000對應的可解密會話數就非常多。
此次漏洞範圍比Heartbleed小, 破壞性小, 利用難度遠大於Heartbleed.
聲明:純翻譯.
0.
DROWN (Decrypting RSA using Obsolete and Weakened eNcryption)涉及兩種攻擊方式:General 和Specific兩種[1].
1.General-CVE-2016-0800
攻擊準備:典型的攻擊場景需要攻擊者被動收集1,000個TLS握手, 與伺服器開啟40,000個SSLv2連接,然後進行2^50次對稱密鑰計算來解密2048位RSA加密的密文.
攻擊結果:
作者使用Amazon EC2,耗費8小時和$440美元完成一次TLS 1.2握手解密,也就是說,可以獲得TLS的會話密鑰,然後解密此次和未來使用此會話重協商的通信.
影響面:
根據掃描結果,33%的https伺服器受此種攻擊的影響[1].
2.Specific-CVE-2015-3197,CVE-2016-0703
攻擊準備:使用OpenSSL的漏洞, 可以被動收集大約1,000個TLS握手, 與伺服器開啟20,000個SSLv2連接,以及非常小的計算量就可以完成攻擊.
攻擊結果:
普通CPU一分鐘即可解密.
影響面:
26%的https伺服器受此種攻擊影響[1].
1.General
SSL/TLS的客戶端已經多年前默認去掉了SSLv2支持, 但伺服器端因為兼容性問題, 仍然存在SSLv2支持.
2.Specific
如CVE-2015-3197所示, 即使OpenSSL 伺服器段禁用了SSLv2相關演算法被禁用, 若客戶端發起SSLv2協商, 仍然可以完成SSLv2握手[4].
細節不用更新了, 看 密碼學專業人員@玄星 的即可, 要點摘要很完善, 補充也很全面. 但不知道為啥被踩了.
據我所知,https登陸時,密碼是明文進入https管道傳輸的,那麼,利用此漏洞,可以恢復出密碼.
但顯然的,費力不討好,不如÷?°￠??¨1￥ 這裡暴力.
根據阿里的供貨商透漏,阿里是"簽發"了大量的證書(密鑰對)部署在不同的伺服器上(即公司認證信息相同,但公私鑰不同),那麼,由於TLS和SSLv2的可能沒恰好使用同一台伺服器,導致攻擊無效.但阿里此種方法涉嫌惡意利用的證書冷備份的問題,存在實際使用量遠大於授權量的現象.
但這並不是大多數公司證書使用的常態, 多數公司的證書被廣泛使用, 即大量系統涉及使用相同的私鑰, 故威脅面大, 但有很多更廉價有效的攻擊方式, 所以實際威脅仍待評估.
1.drown攻擊的論文.
https://drownattack.com/drown-attack-paper.pdf
2.這是OpenSSL官方的通告,可以做引子.
http://openssl.org/news/secadv/20160301.txt
3.Redhat的公告,不熟悉密碼學的建議直接讀這個做初步結論.
https://access.redhat.com/security/cve/cve-2016-0800
4.SSLv2 doesn"t block disabled ciphers ,CVE-2015-3197,
https://www.openssl.org/news/secadv/20160128.txt5.Using SSLv2 as a decryption oracle,CVE-2016-0703,https://access.redhat.com/security/cve/cve-2016-0703
如果我拿到了銀行大門的鑰匙，並且大門鑰匙和裡面保險柜的鑰匙是同一把，那我只需要十天就能偷走裡面所有的錢，想想真是有點小激動呢……
確實沒啥意思
中間人攻擊，難度已經不低期待別人有一個使用sslv2這麼老的早就廢棄了的協議的伺服器使用和新版本協議但是密鑰對相同的伺服器，這個概率很低，尤其是重視安全的網站想想不久之前，淘寶只有登錄請求用https，其他請求還用http呢
測試網站是否受影響：DROWN Attack
中國銀行http://boc.cn：DROWN Attack
看了一下受影響的網站 : https://drownattack.com/top-sites.html驚了
紅帽的評級是比較客觀的，可以參考：https://access.redhat.com/security/cve/cve-2016-0800
就給你說這漏洞垃圾，心臟出血之後openssl也出過一些漏洞 有卵用？ 你都中間人了 幹嘛還用這漏洞搞？條件還相當苛刻。別無腦捧.
還有人用ssl 2.0么
上面「風格」的回答解釋很客觀差不多了，還想補充一下整件事情的大概經過。
如果要說「炒作」，這個漏洞是國外媒體先「炒」起來的。三月二日，也就是昨天早上上午六點，最先在微博上看到小範圍的轉發，而且這個漏洞還沒有中文命名，原微博PO主也並沒有把http://drownattack.com發出來，評論下面好多人在求這個網站。那個時候我百度了一下，DROWN ATTACK關鍵詞，相關的一條搜索結果也沒有，轉到谷歌上搜索，已經可以看到US-CERT的預警和HackerNews 的報道了，有一家外媒甚至用了「the new heartbleed"的標題（傳說中的標題黨）。晚些時候就分別看到了烏雲ZONE和360的播報，所以說，說國內媒體「炒作」這一說法並不不嚴謹。「溺水」攻擊事件本身具有一定危害性，國內安全媒體嗅覺靈敏，面對影響範圍廣的安全事件，這種發布預警的行為值得點贊。
回到事件本身上來，發布這個漏洞的是來自美國密歇根大學和谷歌的研究者們，其中的一個Prof接受了BBC英國廣播公司的採訪。報道參考："Thousands of popular sites" at risk of Drown hack attacks關於這件事情的危害，中間人攻擊確實成本高，解密確實難度大，但是除了這次OpenSSL公開的CVE-2016-0800外，還有一個相關的漏洞，BBC這篇報道以及360的技術博客裡面也均有提及，用你我手頭的電腦就可以搞定，具體細節參考360技術博客，這裡不詳細表述了。
ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] 這幾個哪些是不安全的？除了這次的SSLv2 哪些是不安全？
一切沒有exp的漏洞都不是好漏洞 (?`?′?)
exp放出來了才能知道到底有多大影響，就像當年struts2 (? ??_??)?
影響範圍廣這個確實，但破壞性更為嚴重不見得。
一來這個漏洞的利用方法是中間人攻擊，有一定的局限性，也不能直接影響到伺服器和服務端數據。二來看看攻擊成本，雖然漏洞發布方說實現攻擊簡單，但其實破解方式目前來看還是暴力破解(或許不是，關於演算法本身沒有詳細了解，感謝答主提醒)。八個小時也算不上高效。
Even for servers that don』t have these particular bugs, the general variant of the attack, which works against any SSLv2 server, can be conducted in under 8 hours at a total cost of $440.
其實就是讓原本https加密過的流量可解，那http還是明文的呢，你咋不說所有http的站受到威脅更嚴重呢，那百分之70未受到影響的，大部分是http吧？
其實，這個漏洞，有點標題黨...
推薦閱讀：
