编者按：如今，人们依靠的手机和计算机通信、支付、信息交流等都是互联网的一部分。众所周知，在最初设计互联网时，其主要目标是增强通信能力，没有过多考虑安全问题。因此，目前互联网的核心通信协议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的内容，然后通过中间密文逆向解析可以得到明文。当然这样需要做大量的查询，一般情况下，攻击还是很难成立的。当利用填充内容的特性时，攻击就会变得高效很多。如LuckyThirteen，POODLE attack等都利用了padding内容的特性来提高攻击的效率，使攻击具有更强的实用性。

　　Lucky Thirteen攻击

　　利用填充的不确定性，攻击者能够通过修改填充的内容来进行测试。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（PaddingOracle On Downgrade Legacy Encryption），这是针对SSLv3版本协议的漏洞，可以让攻击者破解小段的加密数据[3]。不同的浏览器对于SSL握手失败后采取的行为不同，服务器端在协议握手匹配失败后，会采取降级的措施。如表1（内容来源于《HTTPS权威指南》）所示，开始握手时服务器会选择最高的协议版本给客户端，若握手失败，服务器会重试旧版本的协议，最后很可能被降级到SSL 3版本。而且存在类似Windows上的IE 6浏览器只支持SSL3。攻击者也可以用这种对协议的兼容性使握手降级到SSL 3，然后进行POODLE攻击来劫持会话。

　　造成POODLE攻击的根本原因也是CBC模式在设计上的缺陷，CBC只对明文进行了身份验证，而没有对填充字节部分进行完整性验证。SSL 3在填充方式上是保留密文的最后一字节，填写为填充的长度。但是，规范中没有规定的填充的具体数据内容，也没有被MAC验证，所以就没有规则来确认填充的内容是否被篡改过，只能验证填充的长度是否正确。这样一来，SSL 3的填充就产生了严重的不安全性。

　　在进行POODLE攻击时，攻击者能够截获密文，正常情况下，直接修改填充字节的内容的方法是不可行的，因为如果改变了MAC值时会引发错误，只有当最后整个块都是填充数据时，攻击者才能够可以进行自由的修改并且不会导致MAC校验的失败。正常情况下，攻击者尽管对密文只做了一位修改，也会导致密文解密发生大量的变化，而且解密后的内容也会变成随机内容。实际上，SSL 3在做解密校验时，只需最后的填充长度字节是正确的。在每次攻击尝试时，攻击者将需要解密的块移至最后一块，然后修改倒数第二块的最后一个字节进行查询，一直重复修改直到服务器成功接收修改后的内容。攻击的主要思路是攻击者针对较大的的URL和较小的请求体，通过缩短URL，每次一个字节，直到找到正确填充长度。通过提交足够多次的修改来破解一个字节，最后同步修改URL内容和请求体的大小并循环破解剩余部分。攻击的主要原理是数据块最后一个字节解密后的值为15（假设块大小为16）

　　（Ci[15]）+Cn-1[15]=15

　　Pi[15]+Ci-1[15]=（Ci[15]）=15+Cn-1[15]

　　Pi[15]=15+Cn-1[15]+Ci-1[15]

　　面对这个严重的漏洞，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，并重复上一步骤。攻击者可以利用0x0002大幅度减少可能的取值，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攻击，从RFC2246（TLS1.0）开始的所有TLS RFC建议“以与正确格式化的RSA块不可区分的方式处理错误格式化的消息”。在[6]中，作者展示了这个工作并没有成功实现，提出了四个新的Bleichenbacher侧信道和三个成功的Bleichenbacher攻击针对Java安全套接字扩展（JSSE）SSL/TLS实现和硬件安全家电使用Cavium NITROX SSL加速器芯片。作者成功验证Bleichenbacher攻击还能够成功的对SSL／TLS协议进行攻击，改善工作还需要继续。

　　DROWN攻击

　　Bleichenbacher攻击进一步升级，在2016年，利用PKCS#1v1.5加密填充的遗留问题，结合SSLv2发起了对SSL／TLS近年来较为严重的一场攻击。在[7]中，DROWN（Decrypting RSAusing Obsolete and Weakened eNcryption）攻击威胁到了百万级的服务器。SSLv2虽然是退役的协议，但是还有大量的服务器支持该协议，没有完全移出废弃协议，从而导致严重的后果。利用该漏洞，观察服务器的响应来解密的RSA密文信息。并且利用这个这个漏洞，攻击者可以在没有RSA密钥私钥的情况下，可以完成跨协议的攻击，来解密SSL3或者更高级的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#1v1.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应用上的退役。

　　RC4从设计之初到现在的应用一直非常广泛，其原因在于加密方式简单，效率非常高，在线上实时通讯加解密等方面起着至关重要的作用。如图3 所示，RC4的加密原理并不复杂，加密算法主要分成两部分。第一部分是密钥调度算法（KSA），通过密钥key来初始化S状态。第二部分是伪随机数生成算法（PRGA），通过使用KSA初始化后的S，生成伪随机序列，更新S，如图4所示（来源于Google）。

　　AlFardan等在[9]中分析了RC4的安全性和近几年来RC4出现的种种状况，当RC4被用于TLS加密时，作者设计了实验对TLS进行了纯密文文本恢复攻击。提供了两种明文恢复攻击方法，而且这些攻击也可以实际应用于RC4加密的TLS会话中。其中主要根据Mantin和Shamir等人在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]，它可以是具有基本上均匀概率分布的任何值。现在使用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]中，其中一个攻击通过分析2⁴⁴个RC4密钥的密钥流，发现在最开始的256个字节中都存在着多种偏差。他们通过改进算法，分别处理不同位置的多种偏差。最后的效果能够达到在2³²个数据样本下，破解全部256字节的内容能够达到100。而且在被攻击字符存在已知部分的情况下，数据样本的数量能减少到2²⁸，远低于应该存在的2128的安全性。

　　在现实生活中，这种攻击暂时还是很难实施的。因为最少需要收集2²⁸个数据样本，被动攻击很难在合理的时间内符合要求。就算每秒进行一次连接，也需要8年左右的时间才能收集齐。所以只有进行主动攻击，通过注入JavaScript恶意脚本进行中间人攻击。而且能破解的内容是前2⁵⁶字节，如果浏览器把有效内容放到2⁵⁶字节后，这个攻击就很难得到有效的内容。

　　双字节偏差

　　除了单字节偏差，在RC4流中还发现了存在多字节偏差。与单字节偏移相反，大多数所识别的多字节偏移不是单一位置，而是以规则间隔周期性连续出现在加密流中。

　　在AlFardan等人发布的第二个攻击中，展示了如何使用双字节偏差来破解明文。利用双字节进行攻击时不需要大量不同的RC4密钥加密的样本，在同一个连接上能够获取多个样本，从而有效地减少了需要建立的连接数。而双字节攻击能够在13*230个数据样本下，破解16字节的明文数据内容。为了使目标cookie处于TLS消息中的固定位置，作者在HTTP头中添加了填充，这使得加密的POST请求达到512字节，这也产生了一些额外的开销。按照每小时生成600万个密文的速度进行实验，需要大约2000小时来收集数据。这个攻击构造产生了大量的网络流量，在实际网络中，这个攻击暂时也不能构成威胁，但是证实了双字节偏差确实可以被利用。

　　攻击改进

　　在[10]中，作者提出不变性弱点（Invariance Weakness），这是RC4加密中的存在的L形键模式。它一旦存在于RC4键中，在整个初始化过程中会保持部分置换状态。当由PRGA算法处理时，该完整部分包括置换的最低有效位，通过流的长前缀确定所称伪随机输出流的最低有效位，如图6所示。这些存在偏差的流字节与明文字节进行异或运算，导致从密文到明文的转换存在着泄漏。这些模式通常发生在不同数量的LSB（Least significantbits），单个LSB，2个LSB，3个LSB至7个LSB，分别导致不同类别的弱RC4密钥。

　　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的攻击又向实际可行的边缘推进了一大步。

　　虽然目前对于在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… . InEUROCRYPT，2002

　　2. N. AlFardan and K. G. Paterson. Lucky thirteen： breaking the TLS and DTLS record protocols. InIEEE，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 sidechannels 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. InCryptography，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

　　（作者单位为清华大学）