OpenSSL 4.1.0 finally ships DTLS 1.3, four known bugs included
On October 23, 2026, OpenSSL released version 4.1.0, which adds DTLS 1.3 (RFC 9147) support alongside four known bugs in that same code, two of which make a connection’s return codes lie to the application. If you adopt DTLS 1.3 server-side, do not take SSL_ERROR_WANT_READ or SSL_ERROR_SYSCALL at face value.
October 23, 2026. OpenSSL releases stable version 4.1.0, adding support for DTLS 1.3 — the version of the secure transport protocol built for UDP datagrams, defined by RFC 9147. October 23, 2026, the same day. The release notes list four known bugs in that DTLS code, with no fix status for three of them. October 26, 2026. Help Net Security details how two of those bugs make the return codes reported to applications lie. The headline: DTLS 1.3 arrives with real gains, but also with documented traps waiting for the first server-side adopters.
For anyone running VPN, WebRTC, voice, or IoT over UDP, this is a useful warning: the novelty is real, but for now it is paid for with a state machine that does not always tell the truth.
DTLS 1.3 arrives, four years after TLS 1.3
TLS 1.3 was standardized in 2018; its datagram counterpart, DTLS 1.3, took years more to reach OpenSSL. The gap is not trivial: DTLS has to rebuild over UDP — no ordering guarantee, no reliability, losses and duplicates possible — the guarantees that TLS gets almost for free on TCP. That retransmission and loss-handling layer is exactly where the bugs now concentrate.
The advertised benefits are concrete. DTLS 1.3 brings a much faster handshake, forward secrecy, an optimized header format, and built-in support for post-quantum cryptography — ML-KEM and ML-DSA — which matters for long-lived devices. Phoronix also notes that 4.1.0 ships AVX-512 optimizations for ML-DSA (SHAKE x4) and AES-CBC decryption, plus GREASE (RFC 8701), which sends random reserved values in handshakes to flush out servers that mishandle the unknown.
The consumers of DTLS are precisely the ones that feel handshake latency the most: the WebRTC of video calls, UDP-based VPNs, telephony, live streaming, and a large share of industrial IoT. For them, a shorter handshake is not a detail: it is the time before the call rings, the tunnel comes up, or the sensor answers. It is also for those long-lived devices that built-in ML-KEM and ML-DSA support matters — a device deployed for ten years must be able to negotiate post-quantum without a hardware upgrade.
Four known bugs, two that make the state machine lie
The four bugs listed by the project are documented, not speculative. Two of them concern how OpenSSL reports a connection’s state to the application using it.
The first: a permanent receive failure on a DTLS listener can surface as SSL_ERROR_WANT_READ, the code that tells a program “wait for more data.” The trap is double: polling and the later accept call can miss the error too, leaving the application waiting indefinitely on a connection that is already dead. A ghost connection that never closes is a leaked descriptor and a service that looks alive when it is not.
The second: a retryable write failure on a nonblocking accepted connection can surface as SSL_ERROR_SYSCALL. An application that treats that code as fatal — as most implementations do — will close a connection that still works. Here it is the opposite: a healthy connection killed by excess caution.
The project’s guidance is explicit: code that accepts connections from a DTLS listener should not take SSL_ERROR_WANT_READ or SSL_ERROR_SYSCALL at face value until those two bugs are fixed.
These two bugs bite hardest on nonblocking event-loop servers — Node.js, nginx, anything built around libuv or a reactive state machine — where SSL_ERROR_WANT_READ is treated as a normal “come back later” signal and SSL_ERROR_SYSCALL as an error to propagate. On that kind of code, the first bug leaves a zombie connection hanging on the loop, and the second drops live connections. A classic blocking-thread DTLS server is less exposed, but still affected by the two handshake bugs.
Aborted handshakes and lost tickets
The other two bugs concern negotiation itself. A DTLS 1.3 server can abort a handshake with an unexpected_message alert when the client acknowledges part or all of the server’s first flight before replying — a situation that typically follows packet loss. In plain terms, a network that drops a packet can turn a perfectly legitimate negotiation into a failure.
The fourth involves KeyUpdate, the message a peer sends to switch to fresh keys mid-session. When OpenSSL receives one, it drops every other outstanding post-handshake record from its retransmission buffer. If a NewSessionTicket — which lets the client resume the session later — was lost on its first trip, OpenSSL will not send it again. Session resumption then becomes silently impossible. A fix is in progress for this bug; the other three have no announced status.
What leaves, and what breaks along the way
Version 4.1.0 does more than add. It removes the no-ecdsa and no-ecdh Configure options, because they did not actually disable the implementations they named: a binary built with those flags still carried the code meant to be left out. The project points users to no-ec, which disables elliptic-curve support entirely. That is a semantic fix, but it will break build scripts that relied on the old illusion.
Two more changes can break existing setups. OpenSSL drops the Windows-on-Itanium and Windows CE build targets, and the tsget time-stamping utility now requires the Perl module Net::Curl::Easy, replacing the abandoned WWW::Curl::Easy. Anyone relying on tsget must install the new module before upgrading.
There is one genuine improvement worth noting: the DTLS 1.3 guide ships as the ossl-guide-dtlsv13(7) manual page, a contrast with the often-thin documentation of earlier cryptographic additions.
Beyond the DTLS bugs, the 4.1.0 release is a reminder of a simple operating rule: a major upgrade to a cryptographic library is tested against your own traffic, not only against the project’s unit tests. The four known bugs would have shown up in a harness that exercises packet loss and KeyUpdate — two scenarios most OpenSSL test benches do not cover.
For operators who do migrate, the checklist is short. Pin your OpenSSL version, run the upgrade on a staging listener that replays real traffic, and specifically exercise packet loss and mid-session KeyUpdate — the two triggers behind the documented bugs. Watch for ghost connections that never close and for healthy connections being dropped, since those are the visible symptoms of the two state-machine bugs. The post-quantum and performance gains of DTLS 1.3 are real, but they do not retire the basic rule that a protocol is only as good as the library that speaks it — and this library is currently speaking with four known stutters.
Verdict
If you run a DTLS 1.3 server in production, treat this release as one to adopt with a guardrail: do not take SSL_ERROR_WANT_READ or SSL_ERROR_SYSCALL at face value until the two state-machine bugs are fixed, and add monitoring that detects ghost connections. If you have no strong reason to migrate — post-quantum, faster handshakes — stay on DTLS 1.2, mature and with no documented bug in this release, and wait for the KeyUpdate fix. The lesson extends beyond OpenSSL: a new protocol can ship with its defects written down in black and white, and an operator’s job is not to chase the novelty, but to read the release notes before deploying it.