攻击需要外部组件（可以拦截流量）和内部组件之间的合作，内部组件在被攻击机器上运行，并且能够在 SSL 隧道中注入任意数据（由攻击者选择），以及被攻击的数据片段。被解密。加密和安全社区中大多数人的普遍看法是，当攻击者能够做到这一点时，他对被攻击机器有足够的控制权，可以认为他已经赢了。尽管如此，还是在TLS 1.1（2006 年发布）和其他版本中发布了一个修复程序。

碰巧的是，在 2011 年的互联网上，可能有大量恶意代码通过 Java 和/或 Javascript 在用户的系统上运行，并且这些代码对所述系统上发生的事情具有相当大的影响力。这是 2006 年设想并宣布为“在实践中不可信”的那种超级攻击者。请注意，除了通过一些幻灯片外，BEAST 尚未发布，因此虽然它已在实验室条件下成功运行，但尚不清楚是否在野外建造它是值得的。毕竟，似乎没有人愿意在常规的工业基础上解密 40 位 SSL 连接，尽管这样做很容易计算（“没有人”是指那些追求信用卡号码和银行访问密码的攻击者，而不是政府安全机构——如果您所在国家的特勤局不定期解密 40 位 SSL，那么您有权质疑他们到底用您的税款做了什么）。

一种看待它的方式是，加密和安全研究人员和/或 Web 浏览器供应商未能预见到 Web 架构的演变。另一种看待它的方式是，浏览器供应商正在努力构建一个 Web 结构，从安全角度来看，这种结构从一开始就注定要失败。

以前，这种攻击在原则上被认为是可能的，但在实践中并不构成严重威胁。人们认为，攻击需要选择如此多的明文，以至于攻击不是实际威胁。此外，在网络设置中，没有已知的方法可以让受害者的浏览器以必要的控制级别加密所选的明文（已知如何在 VPN 设置中执行此操作，但对于正在使用网页浏览器浏览网页）。因此，该攻击被认为在现实世界中的相关性有限。

显然，这种信念存在一些漏洞。正如布鲁斯·施奈尔（Bruce Schneier）所写，“攻击总是会变得更好”。换句话说，仅仅因为今天的攻击似乎需要 2 ^{20 个}选择的明文，并不意味着它总是如此——人们将来可能会找到减少所需选择的明文数量的方法。

我可以同情一个论点，即回想起来，社区应该更认真地对待这次攻击。也就是说，事后看来是 20-20，所以我不会太严厉地评价社区。底线：这些事情发生了。我们的理解会随着时间的推移而增长。

该漏洞仅被认为是理论上的，因此所有大型浏览器供应商都选择忽略它。无论如何，据我所知，论文仍然没有发布，但加密社区中的一些人似乎已经理解了这次攻击。