OpenSSL 4.1.0 brings DTLS 1.3 and new build targets
Written by an AI pipeline from the sources listed below and checked automatically for tone and accuracy. It may still contain mistakes, so check the sources for anything important.
OpenSSL 4.1.0 arrives as a feature release that widens the Windows build matrix, adds a handful of low-level optimizations, and finally ships DTLS 1.3 and the GREASE extension mechanism. The changes matter most to teams that compile OpenSSL from source and need to support legacy Windows toolchains or take advantage of newer CPU instructions.
The sections below explain what each change does, how to enable it, and what caveats remain. By the end you will know which new configuration flags to use, how the performance paths are activated, and which DTLS edge cases still require attention.
New build targets for MSVC 2013
OpenSSL 4.1.0 adds the configuration names VC-WIN32-MSVC2013 and VC-WIN64A-MSVC2013. They are not simple aliases; the configurations ship internal helpers that emulate missing C99 features such as designated initializers and flexible array members. The release notes describe these helpers as “bridging the gaps in C99 standard support that are present in MSVC 2013.”
Because the targets are part of the official configuration list, they can be selected with the usual ./config command, for example:
./config VC-WIN64A-MSVC2013
make -j$(nproc)
The same release also drops the older VC-WIN64I (Windows-on-Itanium) and VC-CE (Windows CE) configurations, cleaning up the supported platform matrix. Teams that need to ship binaries for legacy Windows environments can now stay on MSVC 2013 while still receiving the security fixes and new features introduced in OpenSSL 4.1.0. The change eliminates the need to maintain a separate fork for older toolchains.
AVX-512 optimizations for post-quantum and AES-CBC code
The release adds optimized Number-Theoretic Transform (NTT) operations for ML-DSA and ML-KEM on ppc64le, and hand-tuned assembly for the same algorithms on x86_64. On x86_64 the code uses AVX-512 registers, and the SHAKE-X4 implementation for ML-DSA runs four parallel instances per cycle.
AES-CBC decryption also receives AVX-512 and VAES (Vector AES) instruction support on x86_64. These optimizations are enabled automatically when the configure script detects the required CPU extensions, so a build that already uses -march=native will pick them up without any source changes. If the hardware lacks AVX-512, the fallback code path remains unchanged, and the same binary works everywhere; the optimizer simply does not activate the specialized routines.
DTLS 1.3 support and GREASE extension
DTLS 1.3 is now a fully supported mode, documented in the ossl-guide-dtlsv13(7) manual page and aligned with RFC 9147. It provides the same handshake flow and post-handshake authentication mechanisms as TLS 1.3, but over UDP.
A few implementation details are worth noting:
- When a DTLS 1.3
KeyUpdateis received, the library discards any outstanding post-handshake records from the retransmission buffer. This means a pendingNewSessionTicketwill not be resent if the original packet was lost; the release notes flag this as a known issue slated for a future fix. - A permanent receive failure on a DTLS listener can appear as
SSL_ERROR_WANT_READon an accepted connection, potentially causing an application to wait indefinitely. - A retryable write failure on a non-blocking connection accepted from a DTLS listener may be reported as
SSL_ERROR_SYSCALLinstead ofSSL_ERROR_WANT_WRITE, which some applications treat as fatal.
The GREASE mechanism from RFC 8701 is also integrated. When the -grease flag is used during configuration, OpenSSL automatically generates random extension types during the handshake, helping peers ignore unknown extensions and keeping the protocol extensible. A typical configure line looks like:
./config enable-ssl3 enable-tls1_3 -grease
Dropped options and new architecture support
Two configuration options that never truly disabled the underlying code have been removed: no-ecdsa and no-ecdh. The source explains that these flags “did not really disable the implementations” and recommends using no-ec to turn off all elliptic-curve support in one step. This simplifies the build matrix and reduces the chance of accidental partial disables.
OpenSSL 4.1.0 also adds initial support for the Elbrus2000 (e2k) architecture. While the implementation is still early, the presence of a dedicated target means developers targeting that platform can start experimenting without waiting for a separate patch set.
The takeaway
OpenSSL 4.1.0 expands the Windows build matrix with VC-WIN32-MSVC2013 and VC-WIN64A-MSVC2013, letting legacy toolchains stay current. It adds AVX-512-based speedups for ML-DSA, ML-KEM and AES-CBC on x86_64, and it brings DTLS 1.3 and GREASE into the core library.
Teams should switch to the new version to maintain older Windows builds, enable the performance paths automatically, and adopt DTLS 1.3 while watching for the documented edge cases. The release also cleans up unused options and introduces early support for the Elbrus2000 architecture, further streamlining future builds.
Source: OpenSSL 4.1.0 release notes