我已经创建了一个 nginx 配置，仅使用 TLS v1.2 在 Qualsys SSL Labs 上获得了满分，并且我想尝试使用 TLS v1.2 和 v1.3 获得满分。
考虑一下 A+ 和 100% 分数一部分的 nginx.conf 版本的这个片段：
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% 的完美分数吗？
答案1
关于你的实际问题，Qualys SSL 实验室测试工具本身，我们必须深入了解他们的评级系统是如何运作的。
幸运的是，Qualys 已经发布了他们的SSL 服务器评级指南，描述了他们评级 SSL/TLS 配置的方法。
因为你的问题是关于为什么你的分数略低密码强度类别与您所提议的配置相比，让我们特别关注该类别：
密码强度
为了破坏通信会话，攻击者可以尝试破解用于大部分通信的对称密码。密码越强，加密越强，因此破解密码所需的工作量也就越大。由于服务器可以支持不同强度的密码，因此我们制定了一个评分系统，对使用弱密码的行为进行惩罚。为了计算此类别的分数，我们遵循以下算法：
- 从最强密码的分数开始。
- 添加最弱密码的分数。
- 将总数除以 2。
表 5. 密码强度评级指南
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 的配置中，您只使用了 256 位密码（尽管有些密码套件不受欢迎），而在 TLS1.2+TLS1.3 配置中，您使用了 128 位和 256 位密码的混合。
根据他们的评分系统，这解释了为什么您在“密码强度”方面得分较低。
现在，这很大程度上强调了虽然这个工具是一个非常有用的资源（特别是指出实际的错误配置），但过多关注确切的得分而不是查看整个报告并不是一个好主意。
至于什么是合理的 TLS 设置，除非你对自己需要什么有清晰的认识，否则我建议你看一下服务器端 TLS由 Mozilla 的运营安全和企业信息安全团队维护的指导。
特别是他们的“中级”配置在广泛的兼容性和安全性之间取得了良好的平衡，并且有一个用于流行 TLS 服务器的配置生成器，可以方便地将建议的设置转换为实际的服务器配置。
答案2
通过配置 OpenSSL 来排除一些用于 TLS 1.3 的密码，可以以牺牲 TLS 1.3 合规性为代价。
我在这里写了一个简短的操作指南：
TLS 所有事物！ 详细说明如何实现它以及如何为其余操作系统启用最低 112 位等效版本。
您可以在这里看到示例运行的结果这里
请注意 CBC 密码的使用，通常您也希望删除这些密码并仅运行 GCM。但是，由于访问量很大，您可能会冒这个险，而不是强迫每个人都运行常绿版本。（使用常绿版本！）
无论如何，您真正感兴趣的部分是：
密码套件 = TLS_AES_256_GCM_SHA384：TLS_CHACHA20_POLY1305_SHA256
选项 = ServerPreference、PrioritizeChaCha
通过将这些添加到您的 OpenSSL 配置中，您将有效地删除 128 位参数……Nginx 仍将为您执行 TLS 1.2 配置等，因为该二进制文件控制这些设置而不是 OpenSSL。此后，依赖于 OpenSSL 中设置的其余操作系统也将使用这些设置！（强烈推荐）
答案3
Apache 中也一样：
以 root 身份打开控制台并编辑 /etc/letsencrypt/your-ssl.cnf
SSLEngine on SSLProtocol -all +TLSv1.2 +TLSv1.3 SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-SHA
以 root 身份打开控制台并编辑 /etc/ssl/openssl.cnf
root@vps# nano /etc/ssl/openssl.cnf
在 OpenSSL 1.1.1 的配置文件中添加此规则
CipherSuites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
