SSL/TLS 的近年相关攻击研究综述 (一 )

文/韦俊琳

SSL/TLS 的近年相关攻击研究综述 (一 )

文/韦俊琳

学术专栏

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

Lucky Thirteen 攻击

图2 CBC 模式加密解密

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

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

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

表1 浏览器自动降级

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

表2 PKCS#1 v1.5

DROWN 攻击

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

图3 RC4 加密算法

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

AlFardan 等 在[9]中分析了 RC4 的安全性和近几年来RC4出现的种种状况，当RC4被用于TLS 加密时，作者设计了实验对 TLS进行了纯密文文本恢复攻击。提供了两种明文恢复攻击方法，而且这些攻击也可以实际应用于 RC4 加密的 TLS 会话中。其中主要根据 Mantin 和 Shamir等人在RC4流中发现的两个偏差进行的设计。

图4 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]中，其中一个攻击通过分析244个 RC4 密钥的密钥流，发现在最开始的 256 个字节中都存在着多种偏差。他们通过改进算法，分别处理不同位置的多种偏差。最后的效果能够达到在 232个数据样本下，破解全部 256字节的内容能够达到 100。而且在被攻击字符存在已知部分的情况下，数据样本的数量能减少到 228，远低于应该存在的 2128的安全性。

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

双字节偏差

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

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

攻击改进

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

图5 RC4 加密中开始两轮 S0[2]=0 而 S0[1] 0

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

图6 Invariance Weakness

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