修复在 RHEL 4 上运行的 Apache 2.0 上的 BEAST 漏洞

Question

我有一个在 RHEL4 上运行 Apache 2.0 的 Web 服务器。此服务器最近未能通过 PCI 扫描。

原因：SSLv3.0/TLSv1.0 协议弱 CBC 模式漏洞 解决方案：此攻击在 2004 年和 TLS 协议的后续修订版中发现，其中包含对此的修复。如果可能，请升级到 TLSv1.1 或 TLSv1.2。如果无法升级到 TLSv1.1 或 TLSv1.2，则禁用 CBC 模式密码将消除该漏洞。在 Apache 中使用以下 SSL 配置可缓解此漏洞： SSLCipherSuite RC4-SHA:HIGH:!ADH 上的 SSLHonorCipherOrder

简单的修复，我想。我将这些行添加到 Apache 配置中，但它不起作用。显然，
“SSLHonorCipherOrder On”仅适用于 Apache 2.2 及更高版本。我尝试升级 Apache，很快就遇到了依赖关系，看来我必须升级整个操作系统才能升级到 Apache 2.2。我们将在几个月后停用此服务器，因此不值得。

解决方案说“如果无法升级到 TLSv1.1 或 TLSv1.2，则禁用 CBC 模式密码将消除该漏洞。”

我将如何在 Apache 2.0 上执行此操作？这甚至可能吗？如果没有，还有其他解决方法吗？

Answer 1

除了手动编译更新的 Apache 之外，我唯一能想到的就是让 RC4-SHA 成为唯一支持的密码（openssl ciphers RC4-SHA在当前的 openssl 上进行测试以确保它只打印一个密码，您可能想要做同样的事情以确保它与旧的 openssl 上的一些奇怪的旧密码不匹配）：

SSLCipherSuite RC4-SHA

MS 说 Windows XP 支持TLS_RSA_WITH_RC4_128_SHA所以你不应该有任何兼容性问题。

Answer 2

只有两种方法可以在服务器级别“修复”BEAST。

最好的选择是将服务器的 SSL 库升级到支持 TLS v1.1 或更高版本的库（并确保您的客户端也支持它，以便您可以强制他们使用它）。

另一种选择是禁用任何 CBC（密码块链）加密算法并切换到 en ECB（电子代码簿）密码或类似 RC4 的东西（ECB 算法理论上“不太安全”，因为给定的明文输入加密到给定的key 总是映射回相同的密文，这使得它更容易被已知的明文攻击破解，但实际上这不太可能是一个大问题。谷歌（例如）仍然使用 RC4）。

由于您正在运行的服务器已经死了，被埋没了，并且分解这可能不值得构建修补的 Apache 所需的大量工作（您需要单独重建 Apache 和 OpenSSL，以免破坏任何默认情况下需要在您的系统上安装 OpenSSL 版本——如果您做了那么多工作，您也可以将整个系统升级到实际支持的东西），这样您就可以“切换到 ECB Cyphers”作为您可行的解决方案。

如今，BEAST 确实是一种无所事事的攻击——所有流行的浏览器（IE、Chrome、Safari、Opera）都实施了有效的解决方法，并且由于攻击的工作方式，很难在浏览器之外实施（所以apt和yum仍然非常安全）。

今年早些时候，来自 Google 的 Adam Langley 做了一次精彩的演讲，其中概述了您应该关注的一些痛点：SSL 和安全性——虽然 BEAST 获得了提及，但它接近需要担心的事情列表的底部。