似乎保护用户免受 TLS <= 1.0 上的 BEAST 攻击的最简单方法是更喜欢 RC4 甚至完全禁用所有其他 (CBC) 密码套件，例如通过指定类似
SSLCipherSuite RC4-SHA:HIGH:!ADH
在 Apache mod_ssl 配置中。
但是，CBC 的问题似乎已在 TLS >= 1.1 中得到解决；有没有办法为声称支持 TLS 1.1 或 1.2 的客户端（重新）启用这些密码？似乎有一个解决方法：
SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
通过指定仅在 TLS >= 1.1 中可用的密码套件来解决问题。这似乎具有阻止 TLS >= 1.1 客户端使用任何“旧”密码套件的副作用。
真的没有办法明确告诉 mod_ssl 对 TLS >= 1.1 使用 CBC 模式密码，而对 SSL/TLS <= 1.0 只有 RC4？这似乎是安全性和兼容性的最佳组合。
减轻 BEAST 的一种方法是什么都不做。碰巧的是，虽然 BEAST 中使用的漏洞仍然存在，但利用它却相当困难。它需要能够进行跨域请求，并对请求中发送的数据进行高度控制；特别是，它需要“二进制”数据。Duong 和 Rizzo 没有找到绘制平原攻击图的方法<img>标签（产生此类标签的恶意 Javascript，带有攻击者选择的路径：路径进入请求，但它是纯文本的）。在他们的演示中，他们可以使用两个跨域漏洞，一个在 WebSockets 草案版本中，另一个在 Oracle 的 Java 实现中。这两个漏洞都已被修复，因此，现在，BEAST 不再适用（除非您超过一年没有更新浏览器，在这种情况下您可能会遇到更大的问题）。
由于依靠不存在跨域漏洞充其量是脆弱的，因此浏览器供应商还包括了一些额外的对策，包括记录拆分。当浏览器想要发送一个n字节的数据块时，它不是将它放在一个 SSL 记录中，而是将它分成两条记录，第一条记录非常小。记录边界在 SSL/TLS 中没有语义意义，因此您可以在不改变含义的情况下进行这种拆分。但是，每条记录都以根据记录数据计算的MAC和序列号结束，并使用从初始密钥交换派生的一个密钥。这以某种方式充当伪随机数生成器。因此，小记录“模拟”了使 TLS 1.1+ 免受 BEAST 影响的随机 IV 生成。
理想情况下，拆分为0/n：一条没有数据的记录（但仍然带有 MAC），然后是一条带有实际数据的记录。允许零长度记录（根据标准），但有缺陷的客户端和服务器实现不允许它们（特别是 IE 6.0）；取而代之的是，浏览器使用1/n-1拆分，这对于击败 BEAST 一样好，但也适用于几乎所有现有的 SSL/TLS 客户端和服务器。至少 Chrome 和 Firefox去年已经推动了它。
好的解决方案是 TLS 1.1+，但即使在 SSL 3.0 和 TLS 1.0 上，BEAST 问题也可以认为是固定的，至少在 Web 环境中是这样。因此，使用 AES，并感到高兴。
OpenSSL对 BEAST 有一个缓解措施，从 0.9.6d 开始默认启用，因此只要您的 OpenSSL 版本是此版本或更高版本并且您尚未设置SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS，就无需限制密码或禁用 TLS 1.0。
我的理解是 TLS < 1.1 在 CBC 模式下的任何分组密码都容易受到 BEAST 的攻击。同样，据我了解，您唯一的选择是使用 TLS 1.1 或更高版本，或者使用流密码。
或者，当然，您可以使用不受 BEAST 影响的不同协议，例如 SSH :)