OpenSSL 4.1.0 带来 DTLS 1.3 和 GREASE：升级前应测试的内容

OpenSSL 的新版本发布表面上往往看起来只是简单的库替换。然而 OpenSSL 4.1.0 值得更加谨慎对待，因为其主打特性 DTLS 1.3 伴随着四个仅在网络出现异常时才会显现的已知问题。

截至 2026 年 11 月 2 日，OpenSSL 4.1.0 是这一为互联网绝大部分加密连接提供安全保障的工具包的最新功能特性版本。它增加了 DTLS 1.3、GREASE、更快的后量子和 AES 代码路径，以及若干构建变更。对于任何交付使用 OpenSSL 的软件的团队而言，当前面临的问题都很实际：新版本是否值得采纳，应用程序在其已知限制下能否正常运行？

通俗解读 DTLS 1.3

大多数加密网络流量使用的是运行在 TCP 之上的 TLS。TCP 是一种可靠传输协议：它会重传丢失的数据包并按序交付。

DTLS（数据报传输层安全）在 UDP 上提供相同的防护功能，而 UDP 这种传输协议并不提供此类保证。数据包可能会延迟到达、乱序到达甚至根本无法到达。视频通话、VPN、游戏流量以及许多物联网设备都依赖 UDP，因为它速度快，而 DTLS 则是确保它们保持隐私与安全的方式。

DTLS 1.3 在 RFC 9147 中定义，并基于 TLS 1.3 构建。它在保留 UDP 数据报特性的同时，防范窃听、篡改和伪造消息。该规范明确指出了其保证与 TLS 的不同之处，特别是在排序和重放保护方面。因此，你的应用程序仍然必须自行处理某些情况。

关键教训是：在纯净的实验室网络中正常工作的 DTLS 连接说明不了太多问题。真正困难的情况在于丢包、延迟应答、重传，以及与对端不同的实现进行通信。

四个已知 DTLS 问题

发行说明中列出了四个已知问题。它们会影响连接行为和可靠性。公告并未将其描述为严重漏洞，也未报告任何被主动利用的情况。即便如此，每一个问题都是现成的测试用例。

密钥更新可能导致会话票据停止重传（issue #32878）

在 DTLS 1.3 握手之后，服务器可能会发送会话票据。这些票据允许客户端稍后快速重连。如果在发生密钥更新时对端尚未确认这些票据，OpenSSL 可能会清除它们并停止其重传定时器。

密钥更新是一次独立的交互。它并不能证明票据已经送达。如果票据丢失，它可能永远不会被重传。该问题报告包含一个复现用例，展示了在未收到确认的情况下票据被移除。

永久性接收失败可能看似临时故障（issue #33277）

在通过 OpenSSL 的 DTLS 监听器创建的连接上，永久性接收失败可能会被报告为 SSL_ERROR_WANT_READ。该代码通常表示“暂无数据，请重试”。信赖该代码的应用程序可能会在已失效的连接上无限期等待。轮询以及后续的 accept 调用也可能会掩盖此失败状态。

该复现用例涵盖了 DTLS 1.2，因此这关系到所有使用该监听器的用户，而不仅限于 DTLS 1.3 用户。

临时写入失败可能看似致命错误（issue #33278）

这是对应相反的情况。对于通过监听器接收的非阻塞连接，本应直接重试的写入操作可能会返回 SSL_ERROR_SYSCALL 而不是 SSL_ERROR_WANT_WRITE。将此视为致命错误的应用程序可能会关闭本仍正常的连接。

报告发现，通过不同 API 路径构建的 DTLS 服务器返回了正确的重试代码。该问题与基于监听器的连接相关，且不限于 DTLS 1.3。

有效确认可能导致握手中断（issue #33242）

当客户端仅收到服务器首批握手消息的一部分时，它可能会对已到达的记录进行确认。作为服务器的 OpenSSL 4.1.0 可能会对该确认回复 unexpected_message 警报并终止握手。

陷阱在于：由于 OpenSSL 客户端处理这些确认的方式，OpenSSL 与 OpenSSL 之间的测试并不会触发该问题。某个部署即便通过了全部内部测试，在有丢包的网络中配合其他客户端库使用时仍可能发生故障。

GREASE：保持协议的灵活性

GREASE 代表生成随机扩展并保持可扩展性（Generate Random Extensions And Sustain Extensibility），在 RFC 8701 中进行了阐述。

TLS 允许通信双方通告各自支持的特性，并由另一方选择能够识别的选项。这只有在软件会忽略其无法识别的值时才能生效。然而，某些实现反而会拒绝任何不熟悉的内容，导致日后很难向协议添加新特性。

GREASE 故意发送保留且无意义的值。正确的对端会忽略它们；而有缺陷的对端则会在测试阶段及早暴露故障，而不是在数年之后当某个真正的新扩展依赖这种容忍度时才发生异常。对于运维人员来说，其核心在于长期兼容性。请务必检查你的端点、负载均衡器和检测设备（尤其是旧设备）是否能够正确应对。

更快的密码学算法与构建变更

该版本还带来了性能方面的改进：

• ppc64le 平台上的 ML-DSA 和 ML-KEM 优化（这些是后量子签名与密钥交换算法）。
• x86_64 平台上的 ML-DSA 改进，包括通过 AVX-512 加速的 SHAKE。
• 用于 AES-CBC 解密的 AVX-512 和 VAES 优化。
• 全新的 IKEv2 密钥派生函数以及对 Elbrus2000 架构的初步支持。

值得关注的构建变更：

• 新增 MSVC 2013 目标。
• 移除了 Windows-on-Itanium 和 Windows CE 目标。
• 移除了 no-ecdsa 和 no-ecdh 选项。项目方解释称它们实际上从未真正禁用过那些实现。若要禁用椭圆曲线支持，请使用 no-ec.
• 实用工具 tsget 现在依赖于 Net::Curl::Easy.

更快的密码学原语并不意味着应用程序一定会更快。请使用贴合实际的连接模式和工作负载进行度量，而不要仅仅依赖微基准测试。

支持周期决定决策走向

OpenSSL 项目列出了以下上游支持日期：

系列	支持截止日期
OpenSSL 4.1	2027 年 11 月
OpenSSL 4.0	2027 年 5 月 14 日
OpenSSL 3.6	2026 年 11 月 1 日
OpenSSL 3.5 LTS	2030 年 4 月 8 日

因此，与 3.5 LTS 相比，最新版本的维护周期要短得多。请注意，3.6 版本的支持目前即将结束。此外，还要检查你的操作系统或产品供应商所支持的版本，因为打包发布的 OpenSSL 通常遵循供应商的计划，而非上游的计划。

如何安全地评估 OpenSSL 4.1.0

步骤 1：确认是否真正需要它

列出将要使用 DTLS 1.3 的应用程序、使用 DTLS 监听器的应用程序，以及需要长期支持承诺的应用程序。如果都不需要这些新特性，那么继续留在 3.5 LTS 是一个合理的选择。

步骤 2：确认你正在测试的构建版本

在隔离环境中运行测试构建，绝不要直接在生产环境中运行，并确认其版本和构建选项：

openssl version -a

步骤 3：在丢包环境下进行测试，而非仅在良好网络下测试

在 Linux 测试机上，你可以使用 netem在回环接口上添加人为的丢包与延迟，并在其上运行你的 DTLS 客户端和服务端，然后移除该规则：

sudo tc qdisc add dev lo root netem loss 5% delay 50ms
# run your DTLS client/server tests here
sudo tc qdisc del dev lo root

不仅要观察初次连接，还要观察握手后的行为（会话票据、密钥更新）。

步骤 4：针对其他实现进行测试

由于 issue #33242 不会在 OpenSSL 到 OpenSSL 的测试中出现，请在丢包网络下将至少一个非 OpenSSL 的 DTLS 客户端连接到你的服务器。

步骤 5：检查你的错误处理逻辑

如果你使用了 DTLS 监听器，请审查代码如何响应 SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE 以及 SSL_ERROR_SYSCALL。添加超时机制，以避免始终无法成功的“重试”导致连接永久挂起。

步骤 6：如实进行基准测试并重新构建

在实际硬件上针对真实工作负载进行基准测试。重新运行构建流水线，并确认诸如 no-ec 之类的选项能够生成你所期望的配置。

结语

OpenSSL 4.1.0 是一个意义重大的功能特性版本。DTLS 1.3 和 GREASE 增强了数据报安全性和面向未来的兼容性，新的优化可能在受支持的硬件上加速后量子和 AES 计算。然而，采纳新版本绝不仅仅是直接换上新库并看到应用能够启动。四个已知 DTLS 问题为你提供了具体的测试用例，支持窗口相对较短，真正的考验来自于互操作性、故障恢复以及实际工作负载测试。

优势

• DTLS 1.3 为 UDP 流量带来了 TLS 1.3 时代的安全保护。
• GREASE 有助于在脆弱对端破坏未来扩展之前及早捕获问题。
• 在受支持的 CPU 上提供更快的 ML-DSA、ML-KEM 和 AES-CBC 代码路径。
• 更清晰的构建选项：具有误导性的 no-ecdsa 和 no-ecdh 标志已被移除。
• 已知问题被公开记录，并附带复现用例。

劣势

• 支持将于 2027 年 11 月结束，远早于 3.5 LTS。
• 四个已知 DTLS 问题会影响重传、错误报告和握手。
• 监听器的两个问题同样会影响 DTLS 1.2 用户。
• 构建变更可能会破坏现有脚本或目标。
• 性能提升取决于特定硬件，且可能无法传导至应用层。

注意事项

本文仅供学习参考，是对公开发布的 OpenSSL 4.1.0 版本的总结，并非 OpenSSL 官方文档。命令示例仅适用于隔离的测试机，必须根据你自己的环境、接口名称和测试程序进行调整。问题细节和支持日期可能会发生变动，因此在采纳之前，请对照官方 OpenSSL 发行说明、问题追踪系统以及供应商的安全通告验证所有信息。

常见问题解答

• OpenSSL 4.1.0 有哪些新特性？ — 它增加了 DTLS 1.3、GREASE、ML-DSA、ML-KEM 和 AES-CBC 优化、IKEv2 密钥派生函数以及若干构建变更。
• 什么是 DTLS 1.3？ — 它是 TLS 1.3 的数据报版本，在 RFC 9147 中定义，用于加密和保护 UDP 流量。
• 这四个已知 DTLS 问题是安全漏洞吗？ — 公告将其描述为连接行为和可靠性问题，而非严重安全漏洞，且未报告任何被主动利用的情况。
• 这些已知问题会影响 DTLS 1.2 吗？ — 会影响，监听器的两个错误报告问题（#33277 和 #33278）并不限于 DTLS 1.3。
• GREASE 在 TLS 中有什么作用？ — 它发送保留的随机值，以便尽早发现错误拒绝未知扩展的对端，从而保持协议的可扩展性。
• OpenSSL 4.1 的支持周期是多久？ — 上游支持持续至 2027 年 11 月，而 OpenSSL 3.5 LTS 的支持期持续至 2030 年 4 月 8 日。
• 我应该从 OpenSSL 3.5 LTS 升级到 4.1 吗？ — 仅在确实需要其新特性并且能够对其进行充分测试时才建议升级；否则 3.5 LTS 会提供长得多的支持周期。
• 如何在 OpenSSL 构建中禁用椭圆曲线支持？ — 请使用 no-ec 选项；已移除的 no-ecdsa 和 no-ecdh 选项实际上从未真正禁用过那些实现。

标签

#OpenSSL #DTLS13 #TLS #Cryptography #PostQuantum #NetworkSecurity #CyberSecurity #DevSecOps #UDP #InfoSec