当我在Mozilla SSL 配置生成器我得到了一长串 SSL 密码列表。
例如，
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
然而当我访问密码列表它仅为 Nginx 提供两个 SSL 密码。
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
可用的密码越少，安全性就越差吗？如果我向客户提供的密码选项越少，性能就越好，或者其他一些重要特性也会有所调整吗？
答案1
TLS（以及之前的 SSL）的其中一项允许是，在启动安全连接时，服务器和客户端可以（通常必须）协商并就他们相互支持的密码达成一致。
这样做的原因主要是为了兼容性：它允许逐步引入新密码，而不是破坏尚不支持新密码的客户端和服务器之间的连接。
当只使用单一密码而没有协商时，就会发生这种情况。然后，当一方决定放弃旧密码并升级到新密码，而他们这样做时没有与其他方协调，连接就会中断。在单个组织中，协调服务器和客户端的同时升级已经是一项相当繁重的工作，尽管这是可能的，但在整个互联网上，这样的大规模升级当然几乎是不可能的。
因此：密码协商是好的。（至少对于兼容性而言。）
可用的密码较少是否会降低或损害安全性？
不。密码数量并不能确定安全性。
密码本身提供了安全性。
虽然有些密码比其他密码相对更安全（不同的算法或具有更长密钥长度的相同算法，以及提供前向安全可以使一些比其他更安全）而其他的则很弱甚至损坏，仅支持少数而非全部符合您的安全要求的密码并不会带来额外的安全优势。
（稍微要注意的是，您支持的每个密码也需要在软件中实现。因此，更多的密码 == 更多代码 == 出现错误和实现错误的可能性增加...）
如果我向客户提供更少的密码选项，是否会提高性能或调整其他一些重要特性？
不是，尽管不同的密码会具有明显不同的性能统计数据和不同的用例，但上述关于密码越少意味着代码越少、零日漏洞风险越低的警告除外，这密码数量您支持服务器端不会影响性能以任何相关方式。仅支持满足您安全要求的少数密码而不是全部密码不会带来额外的性能优势。
支持的密码越少，兼容性就越差。（因为你通常会将服务器限制为最新和最强的密码，而较旧的客户端可能不支持这些密码，或者这些密码对它们来说计算成本太高。）
记录用户代理字符串，并通过引用如下表格，列出更新 Web 服务器安全设置时会产生的影响。SSL Lab 的用户代理功能 预先。