几乎没有运动的主要原因是“休息”不够实用，无法出现在雷达上。

• BEAST 不再起作用了。首先，它需要一种方法让浏览器中的客户端代码（恶意 Java 或恶意 Javascript）发出跨域请求，并在位级别进行高级控制；解决此问题的两种已知方法（WebSockets 草案版本和 Java VM 实现中的漏洞）已得到修复。其次，浏览器和操作系统添加了解决方法，即1/n-1 拆分：每当要发出 TLS 记录时，都会发送两条记录，第一条记录仅包含一个字节的应用程序数据。此解决方法可防止应用 BEAST。

• RC4 破损仍然是“学术”。一段时间以来，人们就知道 RC4 有一些严重的偏差。最近的结果（2013 年 3 月）是一些系统测量，表明存在比以前想象的更多的偏差，因此实际攻击“只需要”观察几百万个与目标秘密的连接总是在同一个地方。虽然“几百万”相当低，但从攻击者的角度来看，在 Web 环境中仍然不切实际。因此，没有 cookie 通过使用 RC4 在野外被盗。此外，还有一些可能的变通方法更容易在浏览器中实现。

因此，对于客户端 TLS 实现的大规模更新没有真正的动机。事实上，浏览器供应商习惯于每周处理一次比这更具破坏性的漏洞（通常会导致对整个客户端系统的恶意劫持）。甚至不太可能注意到 SSL 中密码学的某种理论上的利用，更不用说采取行动了。使浏览器供应商转向更新版本的原因是对这些加密攻击的宣传。

此外，重要的一点是，用于任何给定连接的协议版本受客户端和服务器软件支持的限制。在大多数服务器升级之前，将客户端支持升级到 TLS 1.2 不会有任何改变。同样，在升级客户端之前，升级服务器支持并不是很有用。这是典型的墨西哥对峙，没有人在其中移动，因为它需要几个不同的供应商同时进行大规模的升级切换。就此而言，这与 IPv6（计划于 2007 年广泛采用）的情况相同。

在实践中，一些广泛使用的浏览器依赖于底层操作系统的 SSL/TLS 代码，因此任何大规模升级都必须等待 Windows XP 的生命周期结束（微软计划在明年）。

我不确定您所说的不支持是什么意思。目前以下浏览器支持 TLS 1.1 和 1.2：

• Chrome - v30 支持 TLS 1.2。在此之前，仅支持 TLS 1.1
• Firefox - v27默认启用 TLS 1.1 和 1.2
• Internet Explorer - v11 从 2013 年 2 月开始支持 TLS 1.2
• Opera - v17 增加了对 TLS 1.2 的支持。版本 10-12 支持 TLS 1.1 和 1.2 但默认禁用它，版本 14-16 支持 TLS 1.1 但不支持 1.2。
• Safari - iOS 上的 v5 和 OS X 上的 v7 增加了对 TLS 1.2 的支持。

BEAST 已在现代浏览器上得到修复。

虽然人们确实应该转向更新的 TLS 版本，但新协议并没有得到大量采用。与未激活较新协议的服务器存在兼容性问题。有关更多信息，请参阅此链接。不过这篇文章已经有将近一年的历史了，所以从那时起可能已经有了改进。

不转移到较新的 TLS 版本的一个合理原因是，开发人员一直在对旧协议应用创可贴来修复任何漏洞。从长远来看，这显然是不可持续的。希望最近对 SSL/TLS 的攻击将促使人们加快向新版本协议的迁移。

Firefox 不支持 TLS 1.2 的原因是他们使用的网络安全服务的安全后端不支持它。实施正在进行中，请参阅此错误报告

更新：截至 2013 年 6 月 13 日，Chrome Canary 现在支持 TLS 1.2，因为相关错误现已修复。