TLS：硬禁用密码vs未列出

Question

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

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

它会导致什么问题？任何我在客户端/服务器SSL通信方面应该小心的事情？

Answer 1

是的，你不需要!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是最普遍被广泛信任的认证机构认证的算法，唯一能够涵盖所有加入问题的密钥交换术语的唯一方法，以及只有那些被指令复制到数十亿个网站的人才不会被“不了解它们，因此无法改进它们，您可能需要RSA。

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

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

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

• 如果您是客户端，请尝试验证以上内容，但如果没有生成信息（SSL/TLS不携带带内），验证除原始大小以外的DHE参数的任何操作都太难。 ECDHE验证的EC显示（非命名）参数非常罕见，但对于命名曲线，尤其是常见曲线（前B组祝福的P-256和P-384），您可以依赖（开放）社区关注他们。

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