在CloudFlare，我们花了大量时间来思考保护客户数据安全的最佳方法。尽管最近出现了一些问题，HTTPS仍然是为web提供加密内容的最佳方式。随着威胁环境的变化，我们试图跟上我们使用的加密原语的最佳实践。我们最近删除了对使用tls1.1+的浏览器的RC4支持。现在我们删除RC4作为首选密码。CloudFlare后面的服务器将倾向于使用基于AES的密码套件进行所有的HTTPS连接，并且在万不得已的情况下只能使用RC4作为密码。我们相信这是对我们的客户的安全保障的正确选择。为什么现在改变？

让我们回到2011年；大多数浏览器支持TLS1.0协议，首选的密码是AES-CBC。运行Intel Sandy Bridge芯片组并支持硬件AES的服务器和消费类电脑刚刚推出。RC4是一个暮年的旧密码。我们几乎不知道，RC4很快就会重新崭露头角。2011年9月，泰国的Duong和Juliano Rizzo发现了一个名为BEAST对抗TLS的攻击。它允许攻击者在网络中拥有特权位置，并能够诱骗用户进入恶意站点—当选择任何基于CBC的密码时，能够解密数据。这是一件大事，社区决定尽力解决这个问题。最直接的解决办法是让服务器选择非CBC密码，唯一得到广泛支持的候选密码是RC4。大多数服务器运营商（包括CloudFlare）做出了改变，很快大部分互联网又恢复了使用RC4加密的状态。今天的环境大不相同。在BEAST之后的几年里，在Windows和OS X上的操作系统级别引入了客户端缓解措施，在不依赖系统提供TLS的浏览器（包括Firefox和Chrome）中也得到了修复。现在，所有主流浏览器都支持TLS 1.2标准，其中AES-CBC不易受BEAST攻击，大多数浏览器支持一种新的加密模式AES-GCM，该模式不易受到任何已知攻击。CloudFlare站点超过43%的流量现在超过TLS 1.2。作为野兽问题的一个解决办法，吱吱作响的老RC4看起来越来越没有必要了。RC4不仅越来越不相干，作为一个野兽的解决办法，也有越来越多的证据表明RC4密码比以前认为的要弱。2013年，RC4中的偏差被用于发现TLS上下文中对该密码的第一次实际攻击。这一攻击并没有完全破解密码，但它确实表明，有27年历史的流密码还有更多的弱点有待发现。对RC4长期安全的信心处于历史最低水平。众所周知的攻击通常是政府研究人员提前数年发现的。如果公众离破解密码还有5年的时间，那么情报机构可能已经破解了。在某种程度上，bruceschneier（和其他人）认为，目前可以由一个拥有适当资源的三个字母的机构实时删除RC4加密。如果我们想将数据保密多年，RC4可能不是加密数据的最佳方式。主动攻击vs被动攻击总之，这给互联网社区留下了一个艰难的决定。我们是放弃RC4还是保留它作为首选密码？选项包括：选择AES-CBC，让老客户容易受到野兽攻击；选择RC4并冒着被加密的通信可以被实时解密的风险，或者一旦RC4被破坏就可以追溯解密。考虑这一点的一个方法是在前向保密方面。我们之前在密钥建立方面提出了前向保密的主题。如果您使用RSA握手与服务器建立TLS连接，并且有人获得了您的私钥，他们可以返回并解密您的对话。使用像ECDHE这样的前向秘密握手可以保护您不受此影响，只要您的加密算法是强的。但是，如果底层加密算法很弱，无论您使用哪种握手，攻击者都可以解密您的对话。这就是RC4的风险所在。当有人最终打破它，所有以前的对话都可以被解密。BEAST的不同之处在于它必须实时完成。攻击者需要在加密会话期间将数据包注入网络。它也是一种"嘈杂"攻击，因为它会导致大量可疑的网络流量。它既需要诱骗某人进入恶意网站，又需要在网络中拥有特权位置才能成功。它不是那种可以针对整个互联网的攻击。如果您选择的密码是安全的，则BEAST不能用于对您的对话进行反向解密。如果RC4被破坏，那么在过去两年里，互联网流量的50%将面临风险。人们普遍认为AES-CBC是一种长期安全的密码，与RC4不同。选择AES-CBC为我们的客户提供了长期的前向保密性，即使如果他们使用的是过时的浏览器和操作系统，它也可能使他们面临很少执行的嘈杂的主动攻击。选择RC4会将客户的数据暴露给任何一个拥有足够先进的加密技术来破解它的政府。面对这一选择，我们宁愿选择AES-CBC来保护客户免受长期威胁。专家们一致认为，是时候从RC4开始了。谁用RC4？我们决定首先降低服务器上RC4密码套件的优先级，而不是完全删除RC4。通常在HTTPS中，客户机让服务器知道它支持哪些密码套件，服务器从中选择最喜欢的密码套件。通过将RC4放在服务器首选项的最后，我们将只在客户端不支持其他任何内容的情况下选择RC4。下表显示了当我们更改密码首选项时发生的情况。

紫色和棕色的线显示了使用RC4密码套件的服务器的连接百分比。当我们改变密码偏好时（在这个图表上大约18:00），这两条线几乎降到了零。绿线和红线表示替换的AES密码套件。底部的蓝线主要表示在不支持AES的旧版本windowsxp上使用internetexplorer的访问者。在这个变化之后，只有0.0009%的访问者使用RC4连接到我们的服务器。仔细看一下这些数据，我们发现了一些有趣的结果。一小部分访客使用的是运行定制移动优化浏览器的candybar手机。我们看到的大多数日志来自使用支持AES的浏览器的个人，但他们手动更改了密码套件的选择以删除它。他们这样做可能是为了优化客户端性能。虽然AES在最近的英特尔处理器上比RC4快，但RC4在硬件上没有加密加速的旧计算机和移动设备上的计算密集度要低。我们不建议出于性能原因选择RC4，因为很快就会有新的有趣的替代品，请看这个博客了解更多细节。现在呢？每个主要浏览器和操作系统都有BEAST的解决方案，因此我们建议用户升级浏览器和操作系统，以利用TLS 1.2和AES-GCM提供的附加保护。我们不再推荐RC4作为BEAST攻击的服务器端缓解措施。当RC4最终被破坏（如果还没有的话），通过CloudFlare上的站点发送的数据将是长期安全的。对于连接TLS 1.2的浏览器，我们更喜欢AES-GCM，对于旧的TLS版本，我们更喜欢AES-CBC。以下是我们新推荐的密码套件列表：EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5型；如果您确实需要支持0.0009%需要RC4的访问者，请尝试以下操作：EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES：EECDH+RC4:RSA+RC4！MD5型；我们更新了CloudFlare面向互联网的SSL密码配置GitHub页面，以反映这一变化。