我们的 PCI 扫描器刚刚通知我们存在 BEAST（针对 SSL/TLS 的浏览器漏洞利用）漏洞
显然，补救措施如下：
受影响的用户应在服务器的 SSL 配置中禁用所有基于块的密码套件，并且仅支持 RC4 密码，这些密码不易完全解决此漏洞。此漏洞已在 TLS 版本 1.1/1.2 中得到解决，但是，在撰写本文时，对这些较新 TLS 版本的支持尚未得到广泛支持，因此很难禁用早期版本。此外，受影响的用户还可以将 SSL 配置为更喜欢 RC4 密码而不是基于块的密码，以限制但不消除暴露
所以，基本上，我们必须只（或至少优先考虑）对 RC4 密码的支持。
我们如何在现有证书上实际执行此操作？
编辑：忘记添加这是一个 Apache (centos) 服务器
密码套件（大部分）与证书正交。基于 RC4 的密码套件是：
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
两者都需要带有 RSA 密钥的证书，并且“适合加密”（即没有标记为仅签名的证书）。您的证书很可能已经适用于此。除此之外，证书与对称加密算法的选择无关。
您的服务器使用的密码套件的配置取决于服务器类型。如果您的服务器是 IIS，请参阅前面的问题，该问题描述了它是如何完成的。
显然，十年前有一个旧草案，其中定义了三个额外的基于 RC4 的密码套件：
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA
TLS_DHE_DSS_WITH_RC4_128_SHA
前两个使用的密钥只有 56 位，这对于严重的安全性来说是不够的（尽管它可能会阻止一些低功率的业余爱好者）；这些是为了遵守当时短暂生效的美国出口规则而定义的。当您的服务器非对称密钥具有 DSS 类型时，第三个密码套件提供了使用具有足够大密钥的 RC4 的唯一方法；它还启用了简洁的完美前向保密。
这些套件不是标准的（它们不在IANA 注册表中），但某些浏览器会使用它们，尤其是 Internet Explorer。我想IIS可以支持它们。
（如今，带有 DSS 密钥的证书非常罕见。）