- OpenSSL 4.1.0 adds DTLS 1.3 support and lists four known bugs in its DTLS code. Only one has a fix in progress.
- Two bugs can make an application misread a connection's state, so error handling around DTLS listeners deserves a review.
- Teams should check their build flags, tsget use and Windows targets before upgrading, because the release removes or changes them.
The release notes are the product
Most software releases lead with what is new. OpenSSL 4.1.0 also says where the new parts do not yet work as they should. That candour helps, but only if someone reads it before the upgrade is scheduled.
The lesson here is that a known-issues list is a decision document. It helps you decide which new features to adopt now and which to leave alone. In this release, the list covers four bugs in the new DTLS code.
What shipped
The OpenSSL Project calls 4.1.0 a feature release. Its headline addition is support for DTLS 1.3, defined in RFC 9147. Help Net Security describes DTLS as the flavour of TLS designed for message-based transports, UDP among them.
The release also adds RFC 8701 GREASE and initial support for the Elbrus2000 architecture. GREASE works by putting random reserved values into handshakes. If a server mishandles a value it has never seen, the problem shows up early, as Help Net Security explains it.
The project also lists performance work for post-quantum algorithms. It added optimized ML-DSA and ML-KEM operations on ppc64le, and optimized ML-DSA operations on x86_64. AES-CBC decryption on x86_64 gets AVX-512 and VAES optimizations.
How the four DTLS bugs work
Two of the bugs concern what OpenSSL tells the application. In the first, a DTLS listener suffers a permanent receive failure. An accepted connection may report it as SSL_ERROR_WANT_READ, a signal that more data is coming. Later polling and accept calls may also fail to surface the failure. The application can keep waiting on a connection that has already failed.
The second bug runs the other way. A write that can safely be retried on a nonblocking connection accepted from a DTLS listener may come back as SSL_ERROR_SYSCALL, not SSL_ERROR_WANT_WRITE. The project warns that a program which handles that result as a fatal error could shut down a connection that is still usable.
One of the other two sits in the handshake and one in post-handshake retransmission after a KeyUpdate. In the third, a DTLS 1.3 server may end a handshake with an unexpected_message alert. The trigger is a client that acknowledges some or all of the server's first flight of messages before sending its own reply. The project says this can occur after packet loss or while the client is still preparing its authentication response.
The fourth involves KeyUpdate, the message that switches a session to fresh keys. Once OpenSSL receives one, it discards every other post-handshake record still waiting in its retransmission buffer. A NewSessionTicket awaiting acknowledgment will not be resent if the first copy was lost. The project's release notes give a fix in progress for this bug, issue #32878. Help Net Security notes that the other three carry no fix status.
Taken together, these bugs affect the code that decides what a failure means. That is where a library's flaws reach an application's behaviour.
A switch that did not switch anything off
One removal deserves a manager's attention. Configure no longer accepts the no-ecdsa and no-ecdh options. The project's stated reason is that they "did not really disable the implementations." Help Net Security spells out the result: builds using either flag still contained the code the flag was meant to exclude.
If a security review or compliance document relied on those flags, it recorded an assurance the build did not deliver. The project itself states that the options did not fully disable the implementations. The replacement is no-ec, which covers elliptic curve support as a whole. The sources do not say how many builds used the old flags. Your team can check its own.
Other changes that can break setups
Build targets for Windows on Itanium and for Windows CE are gone from this release. The tsget utility now uses Net::Curl::Easy in place of the abandoned WWW::Curl::Easy. The project tells anyone relying on tsget to install the new module before upgrading.
What to ask your teams
Ask whether any product uses DTLS, which often runs over UDP. If it does, ask whether the team plans to adopt DTLS 1.3 or the DTLS listener support new in this release. Help Net Security says the bugs fall on those paths.
If the answer is yes, ask how the code handles SSL_ERROR_WANT_READ and SSL_ERROR_SYSCALL. Help Net Security advises against taking those two codes at face value on connections accepted from a DTLS listener until they are fixed. Ask for a test that simulates packet loss.
Ask which build scripts use no-ecdsa or no-ecdh. Ask who uses tsget, and whether any pipeline targets Itanium or Windows CE.
A project that publishes its own flaws gives you the information to choose your pace. The risk is in upgrading without reading what it says.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OpenSSL Project.
