0

在下面的 TSL1.2 密码列表中，为什么要明确禁用 RC4 而不是将其从密码列表中删除。

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!RC4

它会引起什么问题？关于客户端/服务器 SSL 通信，我应该注意什么？

4

1 回答 1

2

是的，您不需要!RC4，甚至-RC4因为您的任何条款都没有添加任何 RC4 密码套件。

为了安全起见，您可能会添加-aNULL或!aNULL因为您的条款确实添加了许多匿名套件。在实践中，许多可能您连接的大多数或所有系统无论如何都不会协商任何匿名套件，但最好确保它们不能协商。

我假设 SSL 实际上是指 TLS 协议，最好至少是 1.1 版。因为 TLS（至少通过 1.2）基于 SSL3 并且与 SSL3 非常相似，所以许多软件和文档继续使用旧名称，但您应该确定您永远不会使用现在被 POODLE 严重破坏的实际 SSL3 协议，并且应该尝试避免 TLS1.0 具有被 BEAST 所利用的暴露 IV 缺陷，尽管大多数堆栈现在使用 1/n（或有时 0/n）记录拆分来充分缓解 BEAST。而且您喜欢的 GCM 密码套件（将它们放在首位）仅在 TLS1.2（或 1.3，如果并且当它最终确定和实施时）中工作。

其他更一般的考虑：

  • 如果您是服务器，则拥有并配置至少一种类型（RSA、DSA、ECDSA）的私钥，该私钥足够强大、正确生成并防止未经授权的泄露，以及来自 CA 的匹配证书链，客户端将信任，使用足够强的签名（当前 sha256 或更好的 RSA-2048 DSA-2048 ECC-224 或更好），并且对于包含正确主机名的大多数应用程序协议（如 HTTPS）。由于 RSA 是广受信任的 CA 最常可认证的算法，因此唯一一个可以涵盖所有密钥交换条款的算法，您已经费心添加，并且唯一一个被那些不这样做的人复制到数十亿网站的指令所涵盖的算法。不了解它们，因此无法改进它们，您可能需要 RSA。

  • 如果您是客户端，请根据可信赖的 CA 验证服务器证书链，并在适用时验证主机名。请注意，OpenSSL 总是（除非被覆盖）对提供的信任库（根或可选的锚点）进行标准加密（签名）和语法（BC KU EK​​U 策略等）验证，但通过 1.0.2 的客户端不会为您检查主机名，而 1.1.0 仅在您明确配置它时才会这样做。OpenSSL 默认不检查 CRL，也不获取它们，不获取 OCSP，AFAICS 甚至还没有检查装订的 OCSP，所以你应该至少添加其中的一些，但我认为很多开发人员不会这样做。

  • 在极少数情况下，使用客户端身份验证，即客户端证书 [ificate]，反映上述情况：希望或同意进行身份验证的客户端必须拥有并使用合适的私钥和证书链，服务器必须对其进行验证，但通常不是主机名，而且绝对不使用装订.

  • 如果您是服务器，请配置足够强大且正确生成的 DHE（称为 tmp_dh）参数——2048 位现在是标准，除非您必须处理无法处理的过时客户端（如 Java 7）；并且取决于 OpenSSL 版本的 ECDHE（称为 tmp_ecdh）参数——P-256 或 P-384 通常是最好的。1.0.2+ 可以并且应该设置为基于ClientHello'auto'自动选择ECDHE；低于 ECDHE 和 DHE 的所有版本，如果您不配置参数，则即使您将它们配置为首选，也不会使用关联的密码套件。

  • 如果您是客户端，请尝试验证上述内容，尽管在没有生成信息（SSL/TLS 不带内携带）的情况下验证除原始大小之外的任何有关 DHE 参数的内容都太难了。在非常罕见的情况下，用于 ECDHE 验证的“显式”（非命名）EC 参数太难了，但对于命名曲线，尤其是常见曲线（由前套件 B 祝福的 P-256 和 P-384），您可以依赖（开放的）社区将注意力集中在他们身上。

  • 如果您在与受攻击者影响的数据相同的记录中发送敏感数据（如 cookie），请不要使用 SSL/TLS 压缩。许多堆栈从不允许 SSL/TLS 压缩，因为对于需要它的应用程序（例如 HTTP[S]），应用程序级压缩通常可以执行得更好、更便宜。

于 2017-07-07T02:03:32.723 回答