我认为没有人知道在任何现代浏览器上利用 BEAST 的任何方法，所以据任何人所知，这些浏览器可能对类似 BEAST 的攻击非常安全。另一方面，潜在的弱点仍然存在，这让人担心有人可能会找到利用该弱点的新方法。

BEAST 利用了 TLS 1.0 中的安全漏洞。关闭整个弱点的原则方法是将浏览器和服务器都更新到 TLS 1.1 或 TLS 1.2。目前，Chrome 支持 TLS 1.1；IE9、IE10、Opera如果设置特殊选项支持TLS 1.1和TLS 1.2，但默认不支持；iOS 5 客户端最高支持 TLS 1.2；Firefox 和 Safari 没有。不幸的是，在建立 TLS 1.1 连接之前，两个端点都必须支持 TLS 1.1，而如今，很少有服务器支持 TLS 1.1 或 TLS 1.2。少数服务器支持 TLS 1.2（例如，带有 mod_gnutls 的 Apache；如果您启用了一些特殊的注册表项，则为 IIS 7；Java 7 上的 Java 应用服务器），但只有极少数。这意味着今天很少有人可以使用 TLS 1.1 或 TLS 1.2。因此，对 BEAST 攻击的原则性修复在今天并未得到广泛部署，

有关更多详细信息，请参阅例如TLS 1.0 JavaScript 注入漏洞 (BEAST)：客户端要做什么？; Rizzo/Duong CBC“BEAST”攻击的安全影响；对于我的服务器上的 TLS 1.0 javascript 注入漏洞，我能做些什么？; 如何使用 OpenSSL 测试 BEAST 攻击？; 为什么以前认为 BEAST 攻击不可信？.

也就是说，一些服务器已经实施了一些变通办法，以帮助缓解利用 TLS 1.0 中的这个弱点的已知方法。这些变通办法是一种“权宜之计”，不会让弱点消失，但它们确实阻止了所有已知的利用弱点的方法。主要的缓解措施是确保双方都使用 RC4，而不是任何基于分组密码的操作模式。服务器可以通过更改其密码套件的顺序来安排这一点。您可以测试您的服务器是否配置为阻止 BEAST 使用此 SSL 测试器。

我能理解你为什么会有这样的印象。最早的攻击使用 WebSockets 来利用这个弱点。后来的一次攻击也展示了如何使用 Java 来利用它。大多数现代浏览器现在已经被修补以改变 WebSockets 的工作方式，因此 WebSockets 不能再被用来利用这个弱点。然而，潜在的弱点仍然存在，如果明天有人发现了一种不使用 WebSockets 或 Java 来利用该弱点的新方法，我认为任何人都不会感到非常惊讶。

Firefox、Chrome、Opera、IE还针对 BEAST 漏洞实施了以下缓解措施：在第一条记录中仅发送一个字节的应用程序数据（对于 CBC 又名 1/n-1 记录拆分）。这并不完美，但它应该有很大帮助。从长远来看，正确的解决办法是让所有人都迁移到 TLS 1.2，但这需要时间。

另一个脚注：虽然许多浏览器开始实现对 TLS 1.1 的支持，但有一个重要的警告。仅打开 TLS 1.1 或 1.2就会导致与有缺陷的服务器的兼容性问题。如果客户端表明它支持较新的 TLS 版本，这些服务器就会失败。因此，浏览器尝试使用 TLS 1.1，但如果失败，它们会使用 TLS 1.0 再次尝试。如果 TLS 1.0 失败，他们将进一步回退到 SSL 3.0。这引入了一个漏洞：中间人可以强制双方回退到 TLS 1.0。

它最近已修复，因此现在处于自动更新状态的大多数浏览器都可以，并且服务器应设置为从 AES 而不是 RC_4 协商，您也可以完全禁用 SSLv2。