OpenSSL 4.1.0 Ships DTLS 1.3: What to Know Before Upgrading

OpenSSL 4.1.0 landed October 23 with the library’s first stable implementation of DTLS 1.3 — the modernized datagram security protocol WebRTC stacks, VoIP infrastructure, and IoT deployments have been waiting on. The release stays API- and ABI-compatible with 4.0, meaning most users can swap the library without a recompile. There is a catch: four documented bugs ship in the new DTLS 1.3 code, and the team is refreshingly honest about every one of them.

What DTLS 1.3 Actually Changes

DTLS is TLS over UDP — built for real-time applications where a late packet is worse than a lost one. WebRTC uses it for data channels. VoIP stacks use it for DTLS-SRTP key exchange. IoT sensors use it because they cannot afford TCP handshake overhead on constrained radios. DTLS 1.2 has served those use cases, but it dates to 2012 and predates TLS 1.3’s security redesign by six years.

DTLS 1.3, defined in RFC 9147, closes that gap. It brings forward secrecy by default, 1-RTT handshakes (with 0-RTT available), and sequence number encryption — a new addition that hides traffic patterns from passive observers by encrypting the sequence number itself using the session’s AEAD cipher. The header shrinks too: the variable-length unified header drops the version field entirely, cutting handshake overhead for constrained devices.

To test DTLS 1.3 locally after upgrading:

openssl s_server -dtls1_3 -cert server.crt -key server.key
openssl s_client -dtls1_3 -connect localhost:4433

Four Known Bugs in the New DTLS Code

OpenSSL documented four issues in the DTLS 1.3 implementation at release. This level of transparency is unusual and worth taking seriously.

• Issue #32878 — KeyUpdate drops post-handshake records: When a DTLS 1.3 KeyUpdate arrives, all outstanding post-handshake records are silently removed from the retransmission buffer. A NewSessionTicket waiting on an ACK will never be resent. Session resumption can break without any error.
• Issue #33277 — Permanent failure looks like SSL_ERROR_WANT_READ: A permanent receive failure on a DTLS listener reports as SSL_ERROR_WANT_READ. The application keeps polling and never sees the real error. Implement external timeouts or this becomes a zombie connection.
• Issue #33278 — Wrong error code on write failure: A retryable write failure on a nonblocking DTLS connection reports SSL_ERROR_SYSCALL instead of SSL_ERROR_WANT_WRITE. Applications that treat SSL_ERROR_SYSCALL as fatal will close connections that are still usable.
• Issue #33242 — Server aborts handshake on early ACK: The DTLS 1.3 server sends an unexpected_message alert when a client acknowledges part of the server’s first flight before sending its response. This can happen routinely after packet loss or while the client is preparing its authentication reply.

The bottom line: DTLS 1.3 in OpenSSL 4.1.0 is a solid foundation for testing and staging. Avoid deploying it in production over lossy network links until 4.1.1 lands. The issue tracker is the place to watch for fixes.

Breaking Changes to Check Before Upgrading

The 4.0 API and ABI compatibility means most upgrades are painless, but three specific items will break existing setups:

• no-ecdsa and no-ecdh removed from Configure: Build scripts using either option will fail. Migrate to no-ec, which disables all elliptic curve functionality. This is the most likely silent break for CI pipelines that build OpenSSL from source.
• Windows CE and Windows-on-Itanium dropped: Build targets VC-CE and VC-WIN64I are gone. Niche, but non-negotiable if you are in that camp.
• tsget now requires Net::Curl::Easy: The certificate management utility switched from WWW::Curl::Easy. Install the new dependency before upgrading: cpan Net::Curl::Easy or apt install libnet-curl-perl.

Post-Quantum Crypto Gets Faster (But the Wire Is Still the Bottleneck)

This release accelerates post-quantum algorithms across multiple architectures: AVX-512 SHAKE x4 for ML-DSA on x86_64, AES-CBC improvements via AVX-512 and VAES, and ML-KEM and ML-DSA NTT optimizations on ppc64le. Independent benchmarks on an AMD EPYC 9D25 show ML-KEM-768 key generation at 16,346 operations per second — roughly 1,200 times faster than RSA-2048 keygen at 13 ops/sec. ML-DSA-65 signs faster than RSA-2048 but verifies at about 40% of RSA’s rate, which matters for verify-heavy workloads.

The real cost of post-quantum is not CPU cycles. An ML-DSA-65 signature is 3,309 bytes — thirteen times larger than an RSA-2048 signature. Key sizes scale similarly. For TLS handshakes over constrained links, the bandwidth overhead is the number to plan around, not the compute time.

GREASE Is Now Built In

OpenSSL 4.1.0 implements RFC 8701 GREASE — Generate Random Extensions And Sustain Extensibility. During TLS handshakes, the library now sends random unused values in cipher suites, extensions, named groups, signature algorithms, and ALPN identifiers. The point is to surface broken implementations that silently reject unknown values before those implementations spread widely. If something in your stack rejects a connection after upgrading to 4.1.0, GREASE is likely exposing an existing interoperability problem in middleware or a TLS proxy.

How to Upgrade

For most users upgrading from 4.0:

1. Check build scripts for no-ecdsa or no-ecdh flags — replace with no-ec
2. If using tsget, install Net::Curl::Easy first
3. Pull the new library — no source recompile needed for most applications
4. Do not enable DTLS 1.3 in production over lossy paths until 4.1.1

The full release notes are on GitHub and the DTLS 1.3 guide is in man ossl-guide-dtlsv13.