引言
波及范围广泛的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”之外，更靠谱的措施是赶紧修补漏洞吧！ 作者介绍：炼石网络CGLab（CipherGateway Lab）成立于2015年，是一个信息安全实验室，侧重密码技术在云计算领域的工程化应用，研究范围包括云计算场景下的新密码算法及协议的安全分析和应用，也涉及传统密码工程化中的漏洞发现、利用、安全防御。转载本文请与作者联系确认：CGLab@ciphergateway.com。【附录一：参考资料】：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跨协议攻击分析
－ END -本文经原作者授权　由炼石网络编辑整理　如需转载请注明版权归原作者所有　如有侵权请联系　我们将及时处理长按识别二维码即可关注"炼石网络CipherGateway"官方微信