OpenSSL 4.1.0 Released With DTLS 1.3 and Post-Quantum Features

Key Takeaways

• OpenSSL has issued version 4.1.0, introducing DTLS 1.3 support, enhanced cryptographic performance, and new developer tools.
• This update is a feature release, not a security patch, and was published on October 23.
• The release includes four known issues primarily affecting DTLS behavior, which require review before deployment.
• Significant performance improvements for ML-DSA and ML-KEM operations are noted, especially on ppc64le and x86_64 systems.

OpenSSL 4.1.0 Released With DTLS 1.3 and Post-Quantum Features

OpenSSL has unveiled version 4.1.0, a significant update that integrates DTLS 1.3 capabilities, accelerates cryptographic processes, and offers new resources for developers building secure network services. This release, made available on October 23, is focused on new features rather than addressing specific security vulnerabilities through patches.

While not a security patch, the update does include several compatibility adjustments and four identified issues that development teams should carefully evaluate prior to implementing the new version.

DTLS 1.3 Integration and Enhancements

A primary highlight of the OpenSSL 4.1.0 release notes is the full inclusion of DTLS 1.3. This follows an earlier preview, OpenSSL 4.1.0 Alpha1, which first introduced the protocol along with GREASE support and initial cryptographic performance enhancements.

Datagram Transport Layer Security (DTLS) is designed to secure applications utilizing unreliable transports like UDP. Unlike TCP, UDP does not guarantee packet delivery or sequential arrival, making DTLS crucial for applications where latency is paramount, such as online gaming and certain streaming services. DTLS provides essential encryption and authentication, maintaining UDP’s inherent characteristics.

Based on RFC 9147, DTLS 1.3 extends the security principles of TLS 1.3 to datagram protocols, effectively preventing eavesdropping, data manipulation, and message forgery. While offering similar security assurances, applications must account for differences in message ordering and replay protection. DTLS is also engineered to manage lost handshake messages without imposing a reliable, ordered stream on application traffic.

OpenSSL 4.1.0 incorporates DTLS support into its SSL listener API. Additional features include GREASE (Generate Random Extensions And Sustain Extensibility), the IKEv2 key derivation function, and initial support for the Elbrus2000 processor architecture. This release improves the performance of ML-DSA and ML-KEM number theoretic transform operations on ppc64le systems. For x86_64 architectures, optimizations include ML-DSA operations, AVX-512 SHAKE processing for ML-DSA, and AVX-512 and VAES enhancements for AES-CBC decryption. Specific benchmark figures were not provided in the release notes.

Configuration Changes and Known Issues

Developers relying on the tsget utility must now install Net::Curl::Easy before upgrading, as it replaces the deprecated WWW::Curl::Easy dependency. OpenSSL has also removed build targets for Windows-on-Itanium and Windows CE, while adding new targets to address gaps in MSVC 2013’s C99 support.

The configuration options ‘no-ecdsa’ and ‘no-ecdh’ have been removed because they did not effectively disable their respective implementations. Teams aiming to disable elliptic curve support entirely should now use the ‘no-ec’ option.

Four documented issues specifically impact DTLS behavior in this release. Firstly, receiving a DTLS 1.3 KeyUpdate can inadvertently remove other pending post-handshake records from the retransmission buffer. If the original packets are lost, critical records like session tickets may not be retransmitted, potentially leading to connection instability. A fix for this issue is anticipated in a future release.

Secondly, error handling for listeners has limitations. A permanent receive failure might be reported as SSL_ERROR_WANT_READ, causing applications to indefinitely wait for data. Conversely, a retryable write failure could incorrectly manifest as SSL_ERROR_SYSCALL, potentially prompting applications to prematurely close functional connections. Furthermore, early client acknowledgments can trigger handshake failures following packet loss.

What You Should Do

• Review the official release notes thoroughly to understand all changes, new features, and especially the four known issues related to DTLS behavior.
• Before deploying OpenSSL 4.1.0 in production environments, conduct comprehensive testing of DTLS-reliant applications, paying close attention to listener error handling and retransmission scenarios.
• Update the tsget utility’s dependency by installing Net::Curl::Easy if applicable to your development workflow.
• If you need to disable elliptic curve support, ensure you use the ‘no-ec’ configuration option, as ‘no-ecdsa’ and ‘no-ecdh’ are no longer effective.
• Monitor for future OpenSSL releases that may include fixes for the documented DTLS issues.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.