问如何决定用nginx设置哪个ssl_protocols和ssl_ciphers？

EN

对此没有一个正确的答案，因为选择密码套件必须是安全性和兼容性之间的适当折衷。在配置生成器上链接的Mozilla服务器端TLS指南解释了不同配置文件的用途：

• 现代兼容性。对于不需要向后兼容性的服务，下面的参数提供了更高级别的安全性。此配置与Firefox 27、Chrome 30、Windows 7上的IE 11、Edge、Opera 17、Safari 9、Android5.0和Java 8兼容。
• 中间兼容性(默认)。对于不需要与传统客户端(主要是WinXP)兼容但仍然需要支持广泛客户端的服务，建议采用这种配置。它与Firefox 1、Chrome 1、IE 7、Opera 5和Safari兼容

• 旧的向后兼容性。这是一个旧的密匙套件，可以与所有客户端一起工作，返回到Windows /IE6。它只应作为最后手段使用。

将TLS1.3添加到这些建议中是在讨论下进行的，但尚未添加。这一推理是从2016年开始的，在RFC 8446将TLS 1.3作为标准提出之前：

2016年12月27日，我认为我们不应该在这里推荐实验版本。我们等待CHACHA20标准化后才将它添加到指南中，TLS1.3也是如此。

同样，Qualys实验室也发布了SSL和TLS部署最佳实践。由于它是(截至2019年6月)最近一次更新于2017年5月，它还提到TLS 1.3仅作为未来的协议，但它解释了以前的版本TLS 1.2的问题：

TLS v1.2应该是您的主要协议，因为它是唯一提供现代身份验证加密(也称为AEAD)的版本。如果您今天不支持TLSV1.2，那么您就缺乏安全性。为了支持老客户端，目前可能需要继续支持TLS v1.0和TLS v1.1。但是，您应该计划在不久的将来使用TLS v1.0。例如，PCI标准将要求所有接受信用卡支付的网站在2018年6月之前取消对TLS v1.0的支持。目前正在进行设计TLS v1.3的工作，目的是消除所有过时和不安全的特性，并作出改进，使我们的通信在今后几十年内保持安全。

SSL实验室服务器测试被更经常地更新，并指出了其他可能的缺陷：

• 所有的TLS_RSA密匙都被标记为弱的，因为它们不提供前向保密:如果私钥在将来被泄露，所有记录的流量都可以使用它解密。
• 所有使用密码块链接CBC的密匙套件都不是自动弱的，但是有许多易受填充甲骨文攻击攻击的实现，因此它们决定将它们都标记为弱。

我们还有一个从2015年5月开始的最佳实践RFC 7525；关于传输层安全(TLS)和数据报传输层安全性(DTLS)的安全使用建议。它的第4.2节给出的建议类似于Mozilla的现代兼容性和Server：

鉴于上述考虑，建议实现和部署下列密码套件：

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

这些密码套件仅在TLS1.2中得到支持，因为它们是经过身份验证的加密( RFC5116 )算法。

在所有这些基础上，“根据你的需要”调整现代形象可能是很好的。

• 从现代兼容性配置文件中删除基于CBC的密文，即删除ECDHE-ECDSA-AES256-SHA384、ECDHE-RSA-AES256-SHA384、ECDHE-ECDSA-AES128-SHA256、ECDHE-RSA-AES128-SHA256
• 只要密钥长度至少为2048位，并使用GCM模式：DHE-RSA-AES256-GCM-SHA384、DHE-RSA-AES128-GCM-SHA256，就可以添加DHE密匙。

Server中的握手模拟部分帮助指出配置不支持的浏览器。这取决于您决定支持它们是否重要，并在该浏览器上添加最强大的加密套件。

是否等待Mozilla关于实现TLS 1.3的建议也是基于意见的。好消息是，TLS1.3已经完全消除了对所有遗留算法的支持，使得选择不好的密码变得更加困难。来自RFC 8446，1.2与TLS 1.2的主要区别：

支持的对称加密算法列表已从所有被视为遗留算法的算法中删除。剩下的都是使用关联数据(AEAD)算法进行身份验证的加密。密码套件的概念已经被改变，将认证和密钥交换机制从记录保护算法(包括密钥长度)和一个哈希(散列)中分离出来，用于密钥派生功能和握手消息认证代码(MAC)。