使用 nginx 和 TLS 1.3 获得完美的 SSL Labs 分数？
Goj*_*ira 4 security ssl nginx openssl debian-stretch
我创建了一个仅使用 TLS v1.2 在 Qualsys SSL Labs 上获得满分的 nginx 配置，我想尝试使用 TLS v1.2 和 v1.3 获得满分。
考虑这个 nginx.conf 版本的片段，它是 A+ 和 100% 分数的一部分：
ssl_protocols TLSv1.2;
ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL;
它抱怨了几个密码套件，但它仍然给出了一个完美的分数：
现在，如果我将 TLS v1.3 作为唯一的配置更改添加到组合中，则分数会发生变化。
ssl_protocols TLSv1.2 TLSv1.3;
密码强度得分为 90%：
我认为那些弱的 CBC 密码很生气：
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp384r1 (eq. 7680 bits RSA) FS WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 4096 bits FS WEAK 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 4096 bits FS WEAK
没有真正完美地删除 CBC 模式密码的好方法，但排除 SHA1、SHA256 和 SHA384 可能会起作用。配置行变为：
ssl_ciphers AES256+EECDH:AES256+EDH:!aNULL:!SHA1:!SHA256:!SHA384;
让我们看看新的分数：
密码套件强度仍然是 90%。
它不再对密码套件的强度感到愤怒：
但显然它对之前失败的握手感到不满：
这让我们想到......旧设备/应用程序成功握手所需的相同密码套件被列为“弱”并在仅启用 TLS 1.2 时通过。以某种方式启用 TLS 1.3 会使那些在开始失败之前通过的弱密码相同。
似乎选择是：要么只启用 TLS 1.2以获得完美的分数，要么也启用 TLS 1.3 但因必要的密码套件而受到限制？这是一种小林丸。
是否有可能在启用 nginx 和 TLS 1.2 和 1.3 的情况下获得完美的 100% 分数？
关于您的实际问题，即关于Qualys SSL Labs测试工具本身的问题，我们必须深入研究他们的评级系统是如何工作的。
幸运的是 Qualys 发布了他们的SSL 服务器评级指南，其中描述了他们对 SSL/TLS 配置进行评级的方法。
由于您的问题是关于为什么您建议的配置之一在密码强度类别中的得分略低，让我们专门关注该类别：
密码强度
为了破坏通信会话，攻击者可以尝试破坏用于大量通信的对称密码。更强的密码允许更强的加密，从而增加破解它所需的工作量。因为服务器可以支持不同强度的密码，我们得出了一个评分系统，惩罚弱密码的使用。为了计算该类别的分数，我们遵循以下算法：
- 从最强密码的分数开始。
- 添加最弱密码的分数。
- 将总数除以 2。
表 5. 密码强度评级指南
Run Code Online (Sandbox Code Playgroud)Cipher strength Score 0 bits (no encryption) 0% < 128 bits (e.g., 40,56) 20% < 256 bits (e.g., 128, 168) 80% >= 256 bits (e.g., 256) 100%
回顾问题中包含的更详细的结果，我们可以看到，在 TLS1.2-only 配置中，您只使用了 256 位密码（即使某些密码套件不赞成），而在 TLS1.2 中。 2+TLS1.3 配置你混合使用 128 位和 256 位密码。
根据他们的评分系统，这解释了为什么您在“密码强度”中的得分较低。
现在，这几乎突出表明，虽然该工具是一个非常有用的资源（尤其是指出实际的错误配置），但过分关注确切的评分而不是查看整个报告并不是一个好主意。
至于什么才是真正合理的 TLS 设置，除非您对自己的需求有一个深刻的了解，否则我建议您查看由 Mozilla 的运营安全和企业信息安全团队维护的服务器端 TLS指南。
特别是他们的“中级”配置在广泛的兼容性和安全性之间取得了良好的平衡，并且有一个用于流行 TLS 服务器的配置生成器，可以方便地将建议的设置转换为实际的服务器配置。
小智 5
通过配置 OpenSSL 排除某些 TLS 1.3 使用的密码，可以以牺牲 TLS1.3 合规性为代价。
我在这里写了一个简短的操作方法：
TLS 一切！ 详细说明如何实现它并为操作系统的其余部分启用 112 位等效项的最低限度使用。
在这里您可以看到示例运行的结果
请注意 CBC 密码的使用，通常您也希望删除这些密码并仅运行 GCM。然而，由于访问的人数较多，您可能会冒这个风险，而不是强迫每个人都运行常青树。（常青树！）
无论如何，您真正感兴趣的部分是：
密码套件 = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
选项 = ServerPreference、PrioritizeChaCha
通过将这些添加到您的 OpenSSL 配置中，您将有效地删除 128 位参数...Nginx 仍将为您执行 TLS 1.2 配置等，因为该二进制文件控制这些设置而不是 OpenSSL。依赖 OpenSSL 中设置的操作系统的其余部分此后也将使用这些！（热烈推荐）