Software 44912 Published by

OpenSSL 4.1.0-beta1 has been released for testing. The two headline additions are native DTLS 1.3 support (RFC 9147) and deeper integration of NIST's finalized post-quantum algorithms, backed by architecture-specific performance optimizations. Other new features include GREASE support, DTLS in the SSL listener API, IKEv2 key derivation, and initial Elbrus2000 CPU support, alongside breaking changes like dropped Windows targets and a tsget dependency swap.



OpenSSL 4.1.0 Beta 1 Ships With DTLS 1.3 and Post-Quantum Support

The OpenSSL Project shipped 4.1.0-beta1 on September 23, opening its next feature line, and the two headline additions are native DTLS 1.3 support and deeper integration of NIST's finalized post-quantum algorithms.

This beta is effectively a preview of where the world's most widely used cryptographic library points over the coming months before a stable launch. As with the betas before it, the build exists primarily to shake out bugs through community testing before the release candidates arrive.

Openssl

OpenSSL is the open-source toolkit behind a large chunk of secure internet traffic. It handles TLS and DTLS, plus a broad pile of primitives, hashes, ciphers, certificates, key exchange, that power web servers, mail systems, VPNs, blockchain nodes, and embedded gear. Because so much software leans on it, the project treats version numbers as actual promises about compatibility.

Keep in mind that the 4.x line is the payoff of several years of hardening. The 4.0 release stabilized the provider architecture that arrived in 3.0 and quietly deleted long-deprecated machinery such as engines and SSLv2/SSLv3 support. 4.1 now builds on that cleared floor.

What Actually Changed

The notes divide changes into two buckets: things that might break or shift behavior, and features that are purely additive. The breakers are a short list, but worth a glance if you maintain Windows builds or lean on the tsget tool.

OpenSSL added MSVC 2013 build targets (VC-WIN32-MSVC2013 and VC-WIN64A-MSVC2013) to bridge gaps in C99 support inside old Visual Studio. Those targets exist mainly to keep older Windows toolchains alive, which is a favor to whoever still maintains a 2013-era build pipeline.

On the other side of the ledger, a few things got axed. The Windows-on-Itanium and Windows CE configuration targets are gone. So are the no-ecdsa and no-ecdh configure options, since they never actually disabled anything. Use no-ec to disable elliptic curve support instead.

The tsget time-stamping utility now wants Net::Curl::Easy rather than the abandoned WWW::Curl::Easy. Install the new dependency before upgrading or the tool simply stops working.

The bulk of the real work lands under performance, though. OpenSSL folded in a set of low-level speedups across the post-quantum and general crypto paths. You get optimized ML-DSA and ML-KEM NTT operations on ppc64le, optimized ML-DSA on s390x and x86_64, AVX-512-tuned SHAKE operations for ML-DSA, and AVX-512 and VAES help for AES-CBC decryption. That AES-CBC optimization is the more mundane of the bunch, but it touches something people actually run every day.

The New Features

The flagship addition is DTLS 1.3, matching RFC 9147. DTLS is the datagram-based cousin of TLS, built for UDP apps that cannot afford TCP's ordered reliability. Think media streaming, WebRTC data channels, internet telephony, online gaming. By mirroring the TLS 1.3 handshake while adding retransmission timers, fragmentation, and replay detection, OpenSSL finally speaks the current DTLS standard.

It also adds GREASE support per RFC 8701, the technique of stuffing throwaway random values into the handshake so new features don't break interop. Small trick, outsized impact, and something the whole industry has quietly leaned on for years without ever crediting it.

The SSL listener API now multiplexes DTLAS alongside TLS, so servers can manage both connection types from a single thread. OpenSSL also adds IKEv2 key derivation for IPsec VPNs and initial support for the Russian-made Elbrus2000 (e2k) CPU architecture. The latter is a curiosity more than a necessity, but it does widen the hardware list.

Where 4.1 Fits

Four-point-one is a feature release, OpenSSL's term for the even-numbered cycles (3.0, 3.2, 4.0, 4.1) that add capability rather than just patch holes. The odd-numbered point releases handle the security work.

The trajectory reads pretty clearly. 3.0 brought the provider architecture. 4.0 stabilized it and stripped legacy code while also slipping in early post-quantum defaults like X25519MLKEM768 and Encrypted Client Hello. 4.1 now closes the loop on protocol completeness and quantum readiness, pushing the three NIST PQC algorithms ML-KEM, ML-DSA, and SLH-DSA into a much more usable state.

It's arguably one of the more meaningful betas in a while, if only because DTLS 1.3 has been on the wishlist for a long time. However, the usual caveat still applies: this is testing material, not something to point your production servers at just yet.

The lifecycle math is worth a glance. The 4.1 line carries an end-of-life date of November 2027, while the current stable 4.0 line stays supported until May 2027. That leaves organizations a fairly narrow window before they'd need to move on from 4.1, though the 4.0.2 point release keeps the door open a bit longer.

Getting and Testing It

The download is a source tarball, openssl-4.1.0-beta1.tar.gz, sitting at roughly 53.0 MiB. Grab it from the OpenSSL downloads page or the GitHub releases, then verify it against the OpenSSL signing certificate.

The official release notes and downloads page are the place to start if you want to build it yourself, and the GitHub issue tracker is where bugs should go once something breaks.