如何决定使用 nginx 设置哪些 ssl_protocols 和 ssl_ciphers？

Question

我最近在我的域中添加了 TLS（letsencrypt with certbot）。它带有一个基本配置options-ssl-nginx.conf，其中包括

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS";

这部分与Mozilla 推荐的相同。

然后我用https://ssldecoder.org和 . 他们抱怨我的服务器不支持 TLSv1.3

问题 1：为什么 ssl_protocols 中没有 TLSv1.3？有什么理由不添加它吗？

使用https://www.ssllabs.com/ssltest检查我的网站显示了一些关于支持的 SSL 密码的投诉：

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA

问题 2：我应该如何决定支持哪些密码？

如果支持的密码越少，则能够访问该站点的设备就越少。但是有没有办法让我判断将有多少（类似于caniuse.com 用于 css，但用于密码）？而且，由于这是优先顺序，客户仍然可以选择他们喜欢的任何人：为什么我不应该支持所有？

Answer 1

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

• 现代兼容性。对于不需要向后兼容的服务，下面的参数提供了更高级别的安全性。此配置与 Windows 7 上的 Firefox 27、Chrome 30、IE 11、Edge、Opera 17、Safari 9、Android 5.0 和 Java 8 兼容。

• 中间兼容性（默认）。对于不需要兼容旧客户端（主要是 WinXP），但仍需要支持广泛客户端的服务，建议使用此配置。它与 Firefox 1、Chrome 1、IE 7、Opera 5 和 Safari 1 兼容。

• 旧的向后兼容性。这是旧的密码套件，适用于所有回到 Windows XP/IE6 的客户端。它应该仅用作最后的手段。

正在讨论将 TLS 1.3 添加到这些建议中，但尚未添加。这个推理是从 2016 年开始的，在 TLS 1.3 被提议作为RFC 8446 中的标准之前：

jvehent 于 2016 年 12 月 27 日

我认为我们不应该在这里推荐实验版本。我们等待 CHACHA20 标准化后再将其添加到指南中，这同样适用于 TLS1.3。

同样，Qualys SSL Labs 发布了SSL 和 TLS 部署最佳实践。由于（截至 2019 年 6 月）上次更新于 2017 年 5 月，它还提到 TLS 1.3 仅作为未来协议，但它解释了 TLS 1.2 之前的旧版本的问题：

TLS v1.2 应该是您的主要协议，因为它是唯一提供现代认证加密（也称为 AEAD）的版本。如果您今天不支持 TLS v1.2，则您的安全性不足。

为了支持较旧的客户端，您现在可能需要继续支持 TLS v1.0 和 TLS v1.1。但是，您应该计划在不久的将来停用 TLS v1.0。例如，PCI DSS 标准将要求所有接受信用卡支付的网站在 2018 年 6 月之前取消对 TLS v1.0 的支持。

目前正在设计 TLS v1.3，旨在删除所有过时和不安全的功能，并进行改进，以确保我们在未来几十年的通信安全。

SSL Labs 服务器测试会定期更新并指出其他可能的弱点：

• 所有TLS_RSA密码套件都被标记为 WEAK，因为它们不提供前向保密：如果将来私钥被泄露，所有记录的流量都可以使用它来解密。
• 所有使用密码块链接的 密码套件CBC都不是自动弱的，但是有太多的实现容易受到填充预言机攻击，以至于他们决定将它们全部标记为 WEAK。

我们还有 2015 年 5 月以来的最佳当前实践RFC 7525；安全使用传输层安全性 (TLS) 和数据报传输层安全性 (DTLS) 的建议。它的第 4.2 节给出了类似于 Mozilla 的现代兼容性和 SSL Labs Server Test 的建议：

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

• 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

这些密码套件仅在 TLS 1.2 中受支持，因为它们是经过身份验证的加密 (AEAD) 算法 [RFC5116]。

基于所有这些，通过例如“调整您的需求”现代配置文件可能就好了

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

SSL Labs Server Test 中的握手模拟部分有助于指出配置不支持的浏览器。由您决定是否支持它们，并添加该浏览器上可用的最强密码套件。

是否等待 Mozilla 关于实施 TLS 1.3 的建议也是基于意见的。对您来说，好消息是 TLS 1.3 完全取消了对所有旧算法的支持，这使得选择不良密码套件变得更加困难。来自RFC 8446, 1.2。 与 TLS 1.2 的主要区别：

支持的对称加密算法列表已从所有被视为传统的算法中删除。剩下的都是带有关联数据的身份验证加密 (AEAD) 算法。密码套件概念已更改为将身份验证和密钥交换机制与记录保护算法（包括密钥长度）和散列分开，以便与密钥派生函数和握手消息身份验证代码 (MAC) 一起使用。