OpenSSL 4.1.0 Brings DTLS 1.3 and GREASE: What to Test Before You Upgrade

A new OpenSSL release always looks like a simple library swap. OpenSSL 4.1.0 deserves more care than that, because its headline feature, DTLS 1.3, arrives with four known issues that only show up when a network misbehaves.

As of November 2, 2026, OpenSSL 4.1.0 is the newest feature release of the toolkit that secures a large share of the internet's encrypted connections. It adds DTLS 1.3, GREASE, faster post-quantum and AES code paths, and several build changes. For any team that ships software using OpenSSL, the questions right now are practical: is the new release worth adopting, and will applications behave correctly with its documented limitations?

What DTLS 1.3 is, in plain words

Most encrypted web traffic uses TLS, which runs over TCP. TCP is a reliable transport: it resends lost packets and delivers them in order.

DTLS (Datagram Transport Layer Security) does the same protective job over UDP, a transport that makes no such promises. Packets can arrive late, out of order, or not at all. Video calls, VPNs, game traffic and many IoT devices rely on UDP because it is fast, and DTLS is how they stay private.

DTLS 1.3 is defined in RFC 9147 and is built on TLS 1.3. It protects against eavesdropping, tampering and forged messages while keeping UDP's datagram behaviour. The specification is careful to say where its guarantees differ from TLS, especially around ordering and replay protection. So your application still has to handle some things itself.

The key lesson: a DTLS connection that works on a clean lab network proves very little. The hard cases are lost packets, delayed replies, retransmissions, and talking to a different implementation on the other end.

The four known DTLS issues

The release notes list four known problems. They affect connection behaviour and reliability. The announcement does not describe them as critical vulnerabilities and does not report any active exploitation. Still, each one is a ready-made test case.

Key updates can stop session-ticket retransmission (issue #32878)

After a DTLS 1.3 handshake, the server may send session tickets. These let a client reconnect quickly later. If the peer has not yet acknowledged those tickets when a key update happens, OpenSSL can clear them and stop their retransmission timer.

A key update is a separate exchange. It does not prove the tickets arrived. If a ticket was lost, it may never be resent. The issue report includes a reproducer showing tickets removed without acknowledgement.

Permanent receive failures can look temporary (issue #33277)

On connections created through OpenSSL's DTLS listener, a permanent receive failure can be reported as SSL_ERROR_WANT_READ. That code normally means "nothing yet, try again". An application that trusts it may wait forever on a dead connection. Polling and later accept calls may also hide the failed state.

The reproducer includes DTLS 1.2, so this matters to anyone using the listener, not only DTLS 1.3 users.

Temporary write failures can look fatal (issue #33278)

This is the mirror image. For a nonblocking connection accepted through the listener, a write that should simply be retried can return SSL_ERROR_SYSCALL instead of SSL_ERROR_WANT_WRITE. An application that treats that as fatal may close a connection that was still fine.

The report found that a DTLS server built through a different API path returned the correct retry code. The problem is tied to listener-based connections and is not limited to DTLS 1.3.

Valid acknowledgements can abort handshakes (issue #33242)

When a client receives only part of the server's first batch of handshake messages, it may acknowledge the records that did arrive. OpenSSL 4.1.0 as a server can answer that acknowledgement with an unexpected_message alert and end the handshake.

Here is the trap: OpenSSL-to-OpenSSL tests do not trigger it, because of how the OpenSSL client handles those acknowledgements. A deployment can pass every in-house test and still fail with another client library on a lossy network.

GREASE: keeping the protocol flexible

GREASE stands for Generate Random Extensions And Sustain Extensibility, described in RFC 8701.

TLS lets each side advertise what it supports, and the other side picks options it understands. That only works if software ignores values it does not recognise. Some implementations instead reject anything unfamiliar, which makes it hard to add new features to the protocol later.

GREASE sends reserved, meaningless values on purpose. A correct peer ignores them. A broken peer fails early, during testing, instead of years later when a real new extension depends on that tolerance. For operators, the point is long-term compatibility. Check that your endpoints, load balancers and inspection devices cope, especially older ones.

Faster cryptography and build changes

The release also brings performance work:

• ML-DSA and ML-KEM optimisations on ppc64le (these are post-quantum signature and key-exchange algorithms).
• ML-DSA improvements on x86_64, including AVX-512-accelerated SHAKE.
• AVX-512 and VAES optimisations for AES-CBC decryption.
• A new IKEv2 key-derivation function and initial Elbrus2000 architecture support.

Build changes to watch:

• New MSVC 2013 targets.
• Windows-on-Itanium and Windows CE targets removed.
• The no-ecdsa and no-ecdh options removed. The project explains they never actually disabled those implementations. To disable elliptic-curve support, use no-ec.
• The tsget utility now depends on Net::Curl::Easy.

A faster primitive does not mean a faster application. Measure with realistic connection patterns and workloads, not only micro-benchmarks.

Support dates shape the decision

The OpenSSL project lists these upstream support dates:

Series	Supported until
OpenSSL 4.1	November 2027
OpenSSL 4.0	14 May 2027
OpenSSL 3.6	1 November 2026
OpenSSL 3.5 LTS	8 April 2030

So the newest release has a much shorter maintenance horizon than 3.5 LTS. Note that 3.6 support ends right about now. Also check what your operating-system or product vendor supports, because packaged OpenSSL often follows the vendor's schedule, not upstream's.

How to evaluate OpenSSL 4.1.0 safely

Step 1: Decide whether you need it

List the applications that would use DTLS 1.3, those that use the DTLS listener, and those that need a long support commitment. If none needs the new features, staying on 3.5 LTS is a reasonable choice.

Step 2: Confirm which build you are testing

Run the test build in an isolated environment, never straight on production, and confirm its version and build options:

openssl version -a

Step 3: Test under packet loss, not just a clean network

On a Linux test machine, you can add artificial loss and delay to the loopback interface with netem, run your DTLS client and server against it, then remove the rule:

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

Watch post-handshake behaviour (session tickets, key updates) as well as the first connection.

Step 4: Test against other implementations

Because issue #33242 does not appear in OpenSSL-to-OpenSSL tests, connect at least one non-OpenSSL DTLS client to your server under packet loss.

Step 5: Check your error handling

If you use the DTLS listener, review how your code reacts to SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE and SSL_ERROR_SYSCALL. Add timeouts so a "try again" that never succeeds cannot hang a connection forever.

Step 6: Benchmark and rebuild honestly

Benchmark your real workload on your real hardware. Re-run your build pipeline and confirm that options like no-ec produce the configuration you expect.

Conclusion

OpenSSL 4.1.0 is a meaningful feature release. DTLS 1.3 and GREASE strengthen datagram security and future compatibility, and the new optimisations may speed up post-quantum and AES work on supported hardware. But adoption is more than dropping in a new library and seeing the app start. The four known DTLS issues give you concrete test cases, the support window is short, and the real proof comes from interoperability, failure-recovery and workload testing.

Merits

• DTLS 1.3 brings TLS 1.3-era protection to UDP traffic.
• GREASE helps catch fragile peers before they break future extensions.
• Faster ML-DSA, ML-KEM and AES-CBC code paths on supported CPUs.
• Cleaner build options: misleading no-ecdsa and no-ecdh flags are gone.
• The known issues are documented openly, with reproducers.

Demerits

• Support ends in November 2027, far sooner than 3.5 LTS.
• Four known DTLS issues affect retransmission, error reporting and handshakes.
• Two listener issues also affect DTLS 1.2 users.
• Build changes may break existing scripts or targets.
• Performance gains depend on specific hardware and may not reach the application level.

Caution

This article is educational and summarises the publicly described OpenSSL 4.1.0 release; it is not official OpenSSL documentation. Commands are examples for an isolated test machine and must be adapted to your own environment, interface names and test programs. Issue details and support dates can change, so verify every claim against the official OpenSSL release notes, issue tracker and your vendor's advisories before relying on it.

Frequently asked questions

• What is new in OpenSSL 4.1.0? — It adds DTLS 1.3, GREASE, ML-DSA, ML-KEM and AES-CBC optimisations, an IKEv2 key-derivation function, and several build changes.
• What is DTLS 1.3? — It is the datagram version of TLS 1.3, defined in RFC 9147, which encrypts and protects traffic over UDP.
• Are the four DTLS known issues security vulnerabilities? — The announcement describes them as connection behaviour and reliability problems, not critical vulnerabilities, and reports no active exploitation.
• Do the known issues affect DTLS 1.2? — Yes, the two listener error-reporting issues (#33277 and #33278) are not limited to DTLS 1.3.
• What does GREASE do in TLS? — It sends reserved random values so peers that wrongly reject unknown extensions are discovered early, keeping the protocol extensible.
• How long is OpenSSL 4.1 supported? — Upstream support runs until November 2027, while OpenSSL 3.5 LTS is supported until 8 April 2030.
• Should I upgrade from OpenSSL 3.5 LTS to 4.1? — Only if you need its new features and can test them well; otherwise 3.5 LTS gives a much longer support window.
• How do I disable elliptic-curve support in an OpenSSL build? — Use the no-ec option; the removed no-ecdsa and no-ecdh options never actually disabled those implementations.

Tags

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