☰

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

tag-icon • tag-icon apache-2.2 ssl tls
修复在 RHEL 4 上运行的 Apache 2.0 上的 BEAST 漏洞

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

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

我认为这是一个简单的修复。我将这几行添加到 Apache 配置中，但没有起作用。显然，
“SSLHonorCipherOrder On”只适用于 Apache 2.2 及更高版本。我尝试升级 Apache，但很快就陷入了依赖地狱，看来我必须升级整个操作系统才能升级到 Apache 2.2。我们将在几个月内停用这台服务器，所以这样做不值得。

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

我该如何在 Apache 2.0 上做到这一点？这可能吗？如果不行，还有其他解决方法吗？

答案1

除了手动编译较新的 Apache 之外，我能想到的唯一办法就是将 RC4-SHA 设为仅有的支持的密码（openssl ciphers RC4-SHA在当前 openssl 上进行测试以确保它只打印一个密码，您可能需要执行相同的操作以确保它与旧 openssl 上的某些奇怪的旧密码不匹配）：

SSLCipherSuite RC4-SHA

MS 表示 Windows XP 支持TLS_RSA_WITH_RC4_128_SHA所以您不应该遇到任何兼容性问题。

答案2

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

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

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

由于您运行的服务器已死机、被埋没并且分解，这可能不值得花费大量精力来构建修补的 Apache（您将需要单独重建 Apache 和 OpenSSL，以免破坏任何需要系统上默认安装的 OpenSSL 版本的东西——如果您正在做这么多工作，您不妨将整个系统升级为实际受支持的系统），因此，这几乎让您将“切换到 ECB Cyphers”作为可行的解决方案。

BEAST 现在是一次毫无意义的攻击——所有流行的浏览器（IE、Chrome、Safari、Opera）都实施了有效的解决方法，并且由于攻击方式在浏览器之外实现起来非常困难（因此apt仍然yum非常安全）。

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

答案3

我发现唯一能让您通过 ssllabs.com 测试的解决方案是将以下四行添加到您的 apache httpd.conf 和 ssl.conf 文件中：

SSLHonorCipher订购

SSL 协议 -全部 +TLSv1 +SSLv3

SSL密码套件 RC4-SHA:HIGH:!MD5:!aNULL:!EDH:!ADH

SSLInsecureRenegotiation 关闭

确保在 ssl.conf 文件中没有重复发布任何这些设置。

现在我的网站获得了 A 级评价。

相关内容