Abstract:
The open source encryption software project LibreSSL released the official version 4.4.0 on October 22, 2026. This is the first stable release of the 4.4.x series and is also shipped with OpenBSD 8.0. The new version brings a number of security fixes, performance improvements, and platform compatibility updates, focusing on removing the eMudhra root certificate with security risks, optimizing the execution efficiency of the SHA-3 algorithm, and fixing multiple issues in the processing of TLS, DTLS, and X.509 certificates.
Learn more:
https://www.libressl.org/
LibreSSL, originally launched by the OpenBSD project, is an encrypted communication software library that focuses on security and code simplicity. It is derived from the OpenSSL code, but during the development process, some old interfaces and complex functions are gradually removed, and continuous adjustments are made for security, maintainability, and modern encryption protocols. LibreSSL not only provides the encryption foundation for OpenBSD, but also has a portable version that can run on various operating systems such as Linux, FreeBSD, NetBSD, macOS, and Windows.One of the most important changes in version 4.4.0 is the adjustment of the default trusted root certificate set. The development team removed eMudhra's emSign ECC Root CA - G3 root certificate from the default cert.pem certificate file because some lower-level certificate authorities in the certificate system used keys with insufficient strength. For compatibility reasons, the developers also added unaffected intermediate certificates.
This adjustment involves the certificate trust mechanism in HTTPS connections. Browsers, operating systems, and encryption software usually use trusted root certificates to determine whether a website certificate is issued by a trusted organization. If a certificate system has security issues such as insufficient key strength, attackers may take advantage of the weaknesses to try to forge certificates or bypass some trust checks. Therefore, removing risky root certificates can help reduce related security risks.
The development team specially reminds you that you need to check the local certificate file when upgrading. Since existing cert.pem, openssl.cnf, and x509v3.cnf files are no longer automatically overwritten when reinstalling LibreSSL, users may need to manually check and merge certificate changes if the package manager does not automatically handle configuration merging. The development team recommends confirming that the root certificate entry "CN=emSign ECC Root CA - G3" is no longer included in cert.pem.
In terms of performance, LibreSSL 4.4.0 improves the implementation of the SHA-3 algorithm and adopts optimization methods such as unrolled loops and interleaved processing to improve the execution efficiency of related calculations. SHA-3 is a cryptographic hash algorithm that can be used for data integrity verification, digital signatures, and other security protocols. This improvement is mainly aimed at the algorithm implementation itself. The actual performance improvement will be affected by the processor architecture, compiler and specific workload.
The new version also improves compilation and runtime compatibility across multiple platforms. On the macOS side, the problem with the netcat (nc) network function has been fixed, and build support for macOS 27.0 has been added. In the Windows environment, the development team fixed some issues under the MSVC compiler, including the ARM64 optimizer generating error codes in constant-time large integer arithmetic codes, and also improved network connections, file reading and writing, and thread synchronization in the Windows compatibility layer.
For Linux and other Unix-like systems, the new version improves SHA assembly support on the AArch64 platform, and adds or improves assembly implementation configurations for RISC-V, MIPS and other architectures. In addition, the CMake build system will now use compiler and linker security mitigation options consistent with the Autotools build method, making software generated by different build processes more consistent in terms of security hardening.
LibreSSL 4.4.0 also contains a number of fixes in terms of TLS and DTLS protocol implementation. The development team improved the processing logic of the TLS 1.3 server when both parties do not have a mutually supported cryptographic group, and corrected some problems in the handshake process. DTLS-related improvements involve handshake message processing, recording sequence numbers, and data queues, aiming to improve connection reliability and consistency of protocol processing.
X.509 certificate verification is another important area of update. The new version fixes issues with URI hostname resolution in certificate name constraints, including correctly handling IPv6 address literals and preventing specially constructed user information from bypassing hostname checks. In addition, the development team also improved logic such as certificate chain verification, email address and subject name checking to further reduce security risks in the certificate parsing and verification process.
LibreSSL 4.4.0 also fixes several defects that may cause memory safety issues, including out-of-bounds writes, out-of-bounds reads, null pointer accesses, and incorrect memory release in some buffers. The development team also adjusted the error handling mechanism of some encryption operations to prevent the program from continuing to use data that has not been properly initialized after failure.
In terms of compatibility, the new version adjusts the TLS 1.3 preferred key exchange group in libtls to X25519MLKEM768. The combination combines the traditional elliptic curve key exchange X25519 with the post-quantum key encapsulation mechanism ML-KEM, aiming to provide future-proof quantum security capabilities for TLS connections. This does not mean that all applications using LibreSSL will automatically enable the same configuration, the specific behavior still depends on how the application calls libtls and its connection settings.
In addition, the development team deprecated a certificate chain interface with a misleading name, tls_peer_cert_chain_pem(), and recommended that developers instead use interfaces such as tls_peer_cert_chain_verified_pem() or tls_peer_cert_bundle_unverified_pem() to more clearly distinguish between verified and unverified certificate chain data. The project also continues to clean up old code, removing protocol processing logic and legacy interfaces that are no longer needed.
The LibreSSL project stated that the new version continues the goal of continuously improving code security, reliability, and portability, and welcomes the community to continue to submit feedback and improvement suggestions. For system maintainers and software developers, 4.4.0 is not only a regular version upgrade, but also contains certificate trust changes and security fixes that require attention.
In general, the focus of LibreSSL 4.4.0 is not to introduce a new encryption algorithm, but to further strengthen the existing encryption infrastructure, optimize the performance of commonly used algorithms, and improve compatibility on different operating systems and processor architectures. For software projects that rely on LibreSSL to establish TLS connections, verify certificates, or process encrypted data, you should check interface compatibility and local certificate configuration before upgrading, and arrange testing and deployment according to your own environment.
Comments