[译]TLS中的RC4被攻破了，现在该怎么办？

原文链接：https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
原文发表时间：2013.3.19

一段时间以来，RC4都被认为是有问题的，但是直到不久前才有利用其弱点的方法。在2011年BEAST被披露后，我们建议使用RC4算法以避免TLS1.0及更早版本中使用的CBC模式密码套件的弱点。这导致使用RC4的比例大幅上升，有说法称其占据了大约50%。

上周，一组研究人员（Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt）发布了一种针对RC4攻击的有效改进，发现了新的弱点和新的利用方法。Matthew Green在他的博客上做了很好的总结，这里是新问题发布时的幻灯片。

目前，这种攻击尚未能实用，因为它需要上百万甚至上亿条使用不同密钥对相同数据进行的加密结果。浏览器需要与服务端建立多个链接才能给攻击者传递足够的数据。一种可能的利用路径是以某种方法使浏览器建立起大量的连接，同时中间人观察并记录传递的信息。

现在我们还是安全的，但是这给研究人员提升RC4攻击方法带来了很大的刺激，这也意味着我们必须要迅速行动起来。

我们(SSL Labs)将会做什么？

• 开始对我们的用户警告RC4的弱点。 RC4已经确认被攻破，当前在TLS中使用已不安全。但是困难在于，对于用户基数特别大的站点来讲，无法100%安全的替换RC4算法。我们现在除了接受它之外别无选择，无论怎么设置，一些用户仍将处于风险之中。
• 如果苹果公司实现了1/n-1 record splitting在他们的协议栈中（唯一没有实现的主流刘浏览器厂商），我们可以认为BEAST已经在客户端有效的缓解了，我们将建议用户使用非RC4的CBC密码套件。 更新：苹果在2013年10月发布的OS X Mavericks中实现了BEAST缓解措施。这意味着BEAST可以被认为得到了有效的缓解。要想了解更多信息，请参看本博文。
• 开始建议使用GCM模式的密码套件。浏览器将毫无疑问的加快对TLS 1.2和GCM密码套件提供支持，站点管理员将因此而收益。
• 更新 “SSL/TLS部署最佳实践”。
• 在不久的将来，更新评级算法，将RC4弱点纳入考量。

建议

SSL/TLS库开发者

• 加强你的协议栈对Lucky 13攻击的防御能力。（译者注：Lucky 13也是一种针对CBC模式密码套件的攻击，2013年2月发布，不过目前各大主流SSL库都已经修复了该问题。PS：漏洞太TM多了）
• 尽快提供对TLS 1.2和GCM模式密码套件的支持。

浏览器厂商

• 尽快提供对TLS 1.2和GCM模式密码套件的支持。
• 尽快实现1/n-1 record splitting以使得CBC模式密码套件在TLS1.0和更早版本中也是安全的。据我们所了解，苹果是唯一尚未对浏览器发布补丁的厂商，无论是OS X还是IOS。（2013年10月发布了）

系统管理员

• 禁用TLS压缩。这种攻击类似于最近的RC4攻击，只不过可实用。（译者注：另外一种针对SSL/TLS的攻击，利用的压缩算法的机制进行。）
• 尽快提供对TLS 1.2和GCM模式密码套件的支持。

TLS工作组

• 恢复TLS中算法的灵活性和多样性。现在AES GCM密码套件是TLS中保证安全的唯一选择，但是我们不应该一直这样。
• 考虑引入新的流密码算法。如果只有一种密码算法可选，是无法提供算法灵活性的。
• 考虑改变CBC的实现，以便解决timing问题（译者注：就是CBC模式算法漏洞产生的根源）。

应用开发者

• 强化会话管理，以提供可靠的和频繁变换的会话cookie，以增加攻击者所需要的时间和请求数量。近年来这种攻击有个趋势：需要攻击者以某种方式控制TLS连接的客户端。大部分这种攻击集中在提取信息中的一小段，比较典型的就是认证集。会话cookie现在是最为热门的目标。既然攻击是否顺利进行取决于需要多少请求，频繁的变换会话cookie是一个很好的深度防御措施。