在下面的TSL1.2密码列表中，为什么要明确禁用RC4而不是将其从密码列表中删除。
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!RC4
它会导致什么问题？关于客户端/服务器SSL通信我应该注意什么？
答案 0 :(得分：2)
是的，您不需要!RC4甚至-RC4，因为您的任何条款都没有添加任何RC4密码套件。
为安全起见，您可以添加-aNULL或!aNULL，因为您的条款执行会添加许多匿名套件。在实践中，许多可能连接到的大多数或所有系统都不会协商任何匿名套件，但最好确保它们不能。但
我认为通过SSL，您实际上是指TLS协议，最好至少是1.1版本。因为TLS（至少通过1.2）基于并且非常类似于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 EKU策略等）验证，但客户端通过1.0.2不会为您检查主机名和1.1.0只有在你明确配置它时才会这样做。 OpenSSL默认不检查CRL并且不提取它们，不提取OCSP，AFAICS甚至没有检查已装订的OCSP，所以你应添加至少其中一些，但我不知道很多开发人员都认为。
在极少数情况下使用客户端身份验证和客户端证书[证书]，镜像上述：希望或同意进行身份验证的客户端必须拥有并使用合适的私钥和证书链，服务器必须验证它，但通常不会主机名，绝对不使用装订。
如果您是服务器，配置足够强大且正确生成的DHE（称为tmp_dh）参数 - 现在是2048位标准，除非您必须处理不能过时的客户端（如Java 7）处理它;并且取决于OpenSSL版本的ECDHE（称为tmp_ecdh）参数--P-256或P-384通常是最好的。 1.0.2+可以并且应该设置为基于ClientHello'自动'选择ECDHE;低于ECDHE以及DHE的所有版本，如果您不配置参数，即使您将它们配置为首选，也不会使用相关的密码套件。
如果您是客户端尝试验证上述内容，虽然验证除了原始大小之外的DHE参数没有生成信息（SSL / TLS不携带带内）的任何内容都太难了。在非常罕见的情况下，'明确'（非命名）EC参数对于ECDHE验证来说太难了，但对于命名曲线，尤其是普通曲线（P-256和P-384受到前套件B祝福），你可以依赖（开放）社区关注他们。
如果您在与受攻击者影响的数据相同的记录中发送敏感数据（如Cookie），请勿使用SSL / TLS压缩。许多堆栈从不允许SSL / TLS压缩，因为对于需要它的应用程序，应用程序级压缩通常可以更好地执行和。 HTTP [S]。