Category: wolfSSL/ wolfCrypt

Are you wondering what Microsoft’s roadmap for the IIS (Internet Information Services) webserver says about post-quantum cryptography? We’re not; read on to find out why.

Not everyone in the financial industry is old enough to remember what it was like to be in the trenches during the Y2K (Year 2000) era, but those that were around for it know that it was expensive both in dollar and human terms. Many dollars and man hours were spent converting years from two digits to four digits. In the end the endeavor to fix the Y2K bug was a victim of its own success. When January 1st, 2000 rolled around, everyone was fine and the financial system just went along all honky dory.

We here at wolfSSL are hoping for the same fate for Y2Q (Years To Quantum). Hopefully, when a cryptographically relevant quantum computer is finally built, everyone will have switched over to post-quantum algorithms. To ensure this is the case, we here at wolfSSL have been hard at work getting ahead of the curve.

That said, we feel your pain. We know that you’ve been conservatively using Microsoft products. Why wouldn’t you; who doesn’t trust Microsoft? Microsoft’s approach has been to prioritize stability over agility which makes sense for now. But you also know that there are timelines to move to post-quantum cryptography. So what are your options?

At wolfSSL, we are currently working on a product that is so new that it does not even have a name!! It will act as an alternative to Microsoft Windows SChannel Library. It will hook into the windows SSPI (Security Support Provider Interface). Why is this important? Because this is how network security is provided to the Windows IIS Webserver. Without even knowing it, IIS will seamlessly become quantum-safe when you pop in wolfSSL’s alternative to SChannel!

Let us know what you think of the concept around this new product. Are you interested in seeing the timeline accelerated and the priority raised? Let us know by reaching out to facts@wolfssl.com.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

The latest release of wolfSSL 5.8.2 comes with key improvements for users of the wolfSSL sniffer.

Multi-Session Sniffer Support

The wolfSSL sniffer now supports decoding multiple TLS sessions, including those using session tickets and session resumption.

This enables more accurate decryption of real-world TLS traffic, where connections are commonly reused for performance.

New ssl_RemoveSession() API

This release also introduces a new API for targeted sniffer session cleanup:

int ssl_RemoveSession(const char* clientIp, int clientPort,
                      const char* serverIp, int serverPort,
                      char* error);

This allows for fine-grained control of cached sessions, helping reduce memory usage which can be integral especially when operating in high traffic environments.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

At wolfSSL, we prioritize strong, modern cryptographic practices—especially for embedded systems where performance, code size, and reliability are critical. While TLS continues to be the standard for securing communications, many early protocol versions have been broken or deprecated due to serious security flaws. Understanding the history of these attacks and their mitigations helps clarify why wolfSSL supports TLS 1.2 and TLS 1.3 only, with hardened configurations and no legacy baggage.

Summary: Vulnerable Versions at a Glance

Protocol	Status	Major Vulnerabilities	Secure with Mitigation?
SSL 3.0	Broken	POODLE, Downgrade Attacks, Renegotiation	No – Do Not Use
TLS 1.0	Deprecated	BEAST, CRIME, RC4 Bias, Renegotiation	Partially (Obsolete)
TLS 1.1	Deprecated	Weak cipher support, Lucky 13, Renegotiation	But not recommended
TLS 1.2	Supported	FREAK, Logjam, DROWN (if misconfigured), Lucky 13, Renegotiation	Yes
TLS 1.3	Recommended	No known practical attacks	N/A – Strongest Option

SSL 3.0 – Broken by Design (1996)

Attack: POODLE

• Exploits predictable padding in CBC mode.
• Allows a MITM to decrypt encrypted messages byte-by-byte.
• Requires protocol downgrade (common with fallback support in legacy clients).

Attack: Renegotiation

• Unpatched versions allow MITM data injection.
• Fixed by RFC 5746.

Mitigation:

• Disable SSL 3.0 entirely.
• No fix is possible within the protocol itself.

TLS 1.0 – Weak Encryption and Block Mode Flaws

Attack: BEAST

• Targets predictable IVs in CBC mode.
• Attacker uses JaveScript injection to decrypt HTTPS cookies via MITM.

Attack: CRIME

• Exploits TLS compression to infer secret data via length differences in compressed responses.

Attack: Renegotiation

• Unpatched versions allow MITM data injection.
• Fixed by RFC 5746.

Issue: RC4 Bias

• Long-known statistical biases in RC4 keystream make it vulnerable to ciphertext recovery.

Mitigations:

• TLS 1.1 introduced random IVs to mitigate BEAST.
• Disabling TLS compression and RC4 ciphers mitigates CRIME and RC4 bias.
• TLS 1.0 is officially deprecated by wolfSSL and not recommended for any deployments.

TLS 1.1 – Marginal Upgrade, Still Outdated

• Addressed BEAST with random IVs.
• Still lacked support for authenticated encryption (AEAD), forward secrecy by default, and encrypted handshake metadata.

Attack: Lucky 13

• Partial plaintext recovery through adaptive chosen ciphertext attacks when using CBC-mode ciphers.

Attack: Renegotiation

• Unpatched versions allow MITM data injection.
• Fixed by RFC 5746.

Mitigations:

• While safer than TLS 1.0, TLS 1.1 lacks modern protections.
• Use Encrypt-then-MAC (RFC7366) – default in wolfSSL.
• wolfSSL does not support TLS 1.1 by default and does not recommend enabling it unless required for backward compatibility.

TLS 1.2 – Secure When Properly Configured

TLS 1.2 remains widely used and secure when hardened. The vulnerabilities discovered were due to weak configurations or legacy cipher support—not flaws in the protocol itself.

Attack: FREAK

• Exploits fallback to 512-bit “export-grade” RSA keys.
• Attackers brute-force these weak keys to decrypt session data.

Attack: Logjam

• Similar concept to FREAK but targets Diffie-Hellman key exchange with weak 512-bit parameters.

Attack: DROWN

• Targets servers that share a certificate across both TLS and SSLv2.
• Exploits SSLv2 flaws to decrypt TLS data.

Attack: Lucky 13

• Partial plaintext recovery through adaptive chosen ciphertext attacks when using CBC-mode ciphers.

Attack: Renegotiation

• Unpatched versions allow MITM data injection.
• Fixed by RFC 5746.

Mitigations:

• Disable export cipher suites and SSLv2 support.
• Use strong ephemeral key exchange (e.g., ECDHE).
• Use Encrypt-then-MAC (RFC7366).
• Use AEAD ciphers (AES-GCM, ChaCha20-Poly1305).
• wolfSSL provides TLS 1.2 with modern defaults and no export cipher support.

TLS 1.3 – Minimal, Secure, and Efficient

TLS 1.3 removes legacy features that caused vulnerabilities in the past:

• No RC4, no CBC, no static RSA, no compression, no export ciphers.
• Forward secrecy is mandatory.
• Encrypts more of the handshake, preventing downgrade attacks and metadata leakage.
• Streamlined cipher suite negotiation.

Mitigations Built-In:

• TLS 1.3 was designed from the ground up to address all prior attack classes.
• wolfSSL’s TLS 1.3 implementation is FIPS 140-3 Ready and optimized for resource-constrained devices.

wolfSSL Recommendations

As a TLS library optimized for embedded systems, IoT, aerospace, and automotive, we encourage:

1. Use TLS 1.3 wherever possible for reduced code size and maximum security.
2. TLS 1.2 is acceptable when configured with strong ciphers and forward secrecy.
3. Disable legacy protocols (SSL 3.0, TLS 1.0, TLS 1.1) entirely.
4. Audit your build flags to avoid accidental inclusion of weak algorithms.

Conclusion

TLS has evolved from early, flawed implementations to strong, modern protocols that protect billions of connections daily. But only by disabling old versions and enforcing hardened configurations can systems stay secure. wolfSSL supports only TLS 1.2 and TLS 1.3, giving you confidence that your embedded or server deployments are resilient against both legacy and modern threats.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

The RH850 Family of 32-bit automotive microcontrollers (MCUs) is an automotive microcontroller equipped with an integrated Hardware Security Module (HSM). It ensures fast and secure key management, cryptographic processing, and authentication at the hardware level. Designed for next-generation ECUs, it combines functional safety with advanced security.

wolfSSL has now provided a wolfCrypt use case on Renesas RH850 using Renesas CS+ in our wolfSSL Examples GitHub repository. The Github repository contains client and server examples that set up and test various types of connections. In addition to these clients/servers, we have included examples that demonstrate how to build wolfSSL with specific real time operating systems and TCP/IP stacks for embedded systems and devices, and how to use some features of the library like the certificate manager or wolfCrypt’s public-key functionality.

This time, we added the RSAPSS-Sign-Verify program to the repository. You can find <wolfssl-examples>/Renesas/cs+/RH850/rsapss_sign_verify in the repository. The program is a ready-to-run Renesas CS+ program for RH850. Please follow REAME in <wolfssl-examples>/Renesas/cs+/RH850/, then you can easily enjoy RSA Sign/Verify on your device. We will add more examples in the future.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

As part of our ongoing effort to deliver secure-by-default cryptography, wolfSSL has disabled the MD5 hash algorithm by default in the latest release. Don’t worry, it isn’t going away completely, but just disabled at compile time, by default.

Why Disable MD5?

MD5 has been considered cryptographically broken for many years due to known collision attacks. While it’s still used in legacy systems for non-security-critical purposes, it no longer meets modern security standards. Disabling MD5 by default aligns wolfSSL with best practices and further hardens applications that rely on us for secure communications, and has already been done in FIPS builds of wolfSSL.

What Changed?

MD5 is now disabled by default in the master branch of wolfSSL. We expect this default behavior to be in release 5.8.2 and up. If your application or any third-party dependency attempts to use MD5 without explicitly enabling it, you may encounter build or runtime issues such as:

• Compilation errors involving wc_InitMd5() or other MD5 functions
• Protocol negotiation failures if MD5 is assumed as a supported digest (e.g., in TLS 1.0/1.1 or some legacy certificate chains)
• Unexpected behavior in libraries that rely on MD5 internally but don’t check if it’s available

You can check if MD5 is disabled in your configuration by seeing if NO_MD5 is set at compile time.

How to Re-Enable MD5 (If Needed)

If you’re working in a legacy environment or need MD5 for interoperability reasons, you can explicitly re-enable MD5 support by doing the following.

Builds using autotools:

./configure --enable-md5

Builds using cmake:

mkdir -p build
cd build
cmake .. -DNO_MD5=OFF

We strongly encourage you to audit any use of MD5 in your project before re-enabling it. If it’s being used for digital signatures or certificate verification, consider updating to SHA-256 or stronger algorithms.

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

Here at wolfSSL, we are seeing a lot of interest in AI. Some of the most fascinating developments that are happening are around letting different AI agents communicate with each other. Do those communications need to be secured, authenticated, and integrity checked? Of course!

Enter the A2A (Agent2Agent) protocol, which uses HTTPS as its primary transport layer.

Check out the official A2A protocol implementation links:

• Main A2A Repository
• Python SDK

How can wolfSSL help in this endeavor? Well, it is looking like the government is going to be one of the biggest consumers of AI technology, with a fast and agile uptake of AI technology. If they are going to need cryptography to protect this protocol, it had better be FIPS 140-3 certified! Did we mention our FIPS 140-3 certificate #4718?

This shows the chain of dependencies from the A2A reference library down to the OpenSSL library, which provides the underlying cryptographic functionality:

A2A Reference Library → httpx → httpcore → ssl (Python module) → OpenSSL

We can add wolfProvider and wolfCrypt FIPS to that to bring it into compliance so the government can use it! It would look like this:

A2A Reference Library → httpx → httpcore → ssl (Python module) → OpenSSL → wolfProvider → wolfCrypt FIPS

For extra performance, another option would be to do an integration with wolfssl-py; our python wrapper for wolfSSL.

Interested in seeing this happen? We are! Let us know if you’re interested!

If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

The wolfSSL team is thrilled to announce a monumental update to wolfPKCS11, now available in the master branch on GitHub. This release transforms wolfPKCS11 into a premier, high-performance PKCS#11 provider by incorporating an incredible 42 new cryptographic mechanisms and 8 new API functions. This focused engineering effort enables wolfPKCS11 to serve as a complete and robust backend for Mozilla’s Network Security Services (NSS).

This achievement makes our vision from the “Firefox Gets FIPS 140-3 Power” post a production-ready reality. Now, any application using NSS—including Firefox, Thunderbird, and Linux server products—can be powered by our FIPS 140-3 validated wolfCrypt engine, bringing federally certified security and our signature performance and efficiency to the entire NSS ecosystem.

The Strategic Advantage: FIPS-Powered NSS

PKCS#11 is the industry-standard API for communicating with cryptographic hardware and software modules. NSS uses a PKCS#11 module to perform all its cryptographic operations. Our update provides the comprehensive support NSS requires, allowing wolfPKCS11 to act as a “drop-in” bridge to our wolfCrypt engine.

This integration provides a simple and efficient pathway to FIPS compliance for organizations in regulated industries. Instead of complex and costly application overhauls, using wolfPKCS11 with a FIPS-validated wolfCrypt backend becomes a straightforward configuration change, saving immense time and resources.

Feature Highlights: A New Level of Capability

The 42 new mechanisms expand wolfPKCS11’s capabilities to cover the full spectrum of modern cryptographic needs. Key additions include:

• Modern Signatures: Support for the modern and provably secure RSA-PSS signature schemes (CKM_SHA256_RSA_PKCS_PSS, etc.), which are more resilient against cryptographic attacks than older standards.
• Advanced Key Derivation: The inclusion of the HMAC-based Key Derivation Function (HKDF) and specific TLS and NSS mechanisms allows applications to offload their entire TLS key schedule to a FIPS-certified boundary.
• Comprehensive Algorithm Support: A full suite of SHA-2 and SHA-3 hashing algorithms, along with advanced AES capabilities like CKM_AES_KEY_WRAP_PAD for secure key management, ensures broad compatibility and robust security.

In addition to new mechanisms, the 8 new API functions provide developers with advanced control for sophisticated applications. Functions like C_GetOperationState and C_SetOperationState allow for saving and restoring the progress of cryptographic operations, which is critical for resilience in embedded systems. Others, like C_VerifyRecover, add support for specialized signature schemes, ensuring comprehensive standards compliance.

Quality, Reliability, and Getting Started

This release is reinforced by significant under-the-hood improvements. A new –enable-nss compile-time option streamlines integration, and our vastly improved CI pipeline now includes extensive regression testing against the NSS suite, static analysis, and dynamic sanitizers to guarantee stability. We’ve also included numerous fixes for TPM users and improved the handling of object attributes for greater security and reliability.

The latest updates transform wolfPKCS11 into a fully-featured, highly reliable, and FIPS-capable PKCS#11 implementation. It is now uniquely positioned to bring the industry-leading performance and certified security of wolfCrypt to the entire ecosystem of applications built on NSS.

Developers are encouraged to explore these powerful new features, which are available now on the master branch of the official wolfPKCS11 GitHub repository. For hands-on examples of how to use wolfPKCS11 with NSS, please see our dedicated examples repository.

• wolfPKCS11 Main Repository
• Usage Examples

For any technical questions, please reach out to us at support@wolfssl.com. For inquiries related to FIPS 140-3 validation, commercial licensing, or questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL 5.8.2 is now available! We are excited to announce the release of wolfSSL 5.8.2, packed with significant enhancements, introducing new functionalities, and refining existing features!

Important Notes for this Release

• GPLv3 Licensing: wolfSSL has transitioned from GPLv2 to GPLv3.
• Deprecated Feature: `–enable-heapmath` is now deprecated.
• MD5 Disabled by Default: For enhanced security, MD5 is now disabled by default.

Key Highlights of wolfSSL 5.8.2

Vulnerability Mitigations:

• ECC and Ed25519 Fault Injection Mitigation (Low): (Thanks to Kevin from Fraunhofer AISEC)
• Apple Native Cert Validation Override (High – CVE-2025-7395): (Thanks to Thomas Leong from ExpressVPN)
• Predictable `RAND_bytes()` after `fork()` (Medium – CVE-2025-7394): (Thanks to Per Allansson from Appgate)
• Curve25519 Blinding Enabled by Default (Low – CVE-2025-7396): (Thanks to Arnaud Varillon, Laurent Sauvage, and Allan Delautre from Telecom Paris)

New Features:

• Sniffer Enhancements: Support for multiple sessions and a new `ssl_RemoveSession()` API for cleanup.
• New ASN.1 X509 API: `wc_GetSubjectPubKeyInfoDerFromCert` for retrieving public key information.
• PKCS#12 Improvements: `wc_PKCS12_create()` now supports PBE_AES(256|128)_CBC key and certificate encryptions.
• PKCS#7 Decoding: Added `wc_PKCS7_DecodeEncryptedKeyPackage()` for decoding encrypted key packages.
• Linux Kernel Module Expansion: All AES, SHA, and HMAC functionality now implemented within the Linux Kernel Module.
• OpenSSL Compatibility Layer Additions: New APIs for X.509 extensions and RSA PSS: `i2d_PrivateKey_bio`, `BN_ucmp`, and `X509v3_get_ext_by_NID`.
• Platform Support: Added support for STM32N6.
• Assembly Optimizations: Implemented SHA-256 for PPC 32 assembly.

Improvements & Optimizations:

This release includes a wide range of improvements across various categories, including:

• Extensive Linux Kernel Module (LinuxKM) Enhancements: Numerous minor fixes, registrations, and optimizations for cryptography operations within the Linux Kernel Module.
• Post-Quantum Cryptography (PQC) & Asymmetric Algorithms: Updates to Kyber, backward compatibility for ML_KEM IDs, fixes for LMS building and parameters, and OpenSSL format support for ML-DSA/Dilithium.
• Build System & Portability: General build configuration fixes, improvements for older GCC versions, new CMakePresets, and default MD5 disabling.
• Testing & Debugging: Enhanced debugging output, additional unit tests for increased code coverage, and improved benchmark help options.
• Certificates & ASN.1: Improved handling of X509 extensions, fixed printing of empty names, and better error handling.
• TLS/DTLS & Handshake: Corrected group handling, improved DTLS record processing, and refined TLS 1.3 key derivation.
• Memory Management & Optimizations: Stack refactors, improved stack size with MLKEM and Dilithium, and heap math improvements.
• Cryptography & Hash Functions: Added options to disable assembly optimizations for SipHash and SHA3, and improved Aarch64 XFENCE.
• Platform-Specific & Hardware Integration: Explicit support for ESP32P4, public `wc_tsip_*` APIs, and enhanced PlatformIO certificate bundle support.
• General Improvements & Refactoring: Updated libspdm, fixed PEM key formatting, and improved API accessibility for certificate failure callbacks.

wolfSSL 5.8.2 also includes some nice bug fixes, addressing issues across various modules, ensuring greater stability and reliability. For a complete and detailed list of all changes, please refer to the full release notes.

We encourage all users to upgrade to wolfSSL 5.8.2 to take advantage of these important security updates, new features, and performance enhancements. Download the latest release.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

How wolfSSL and Dark Sky Technology Secure Embedded Systems

When defense systems run open-source code touched by foreign adversaries, it’s not just risky—it’s a national security threat. That’s why wolfSSL and Dark Sky Technology teamed up: to combine certifiable cryptography with provable trust.

wolfSSL builds the most trusted cryptography on the market. Our lightweight, FIPS 140-3 validated wolfCrypt library secures everything from satellites to submarines—where performance, footprint, and reliability are non-negotiable. We support secure boot, secure firmware updates, and full (D)TLS 1.3, all engineered to meet the toughest standards like DO-178C DAL A and CNSA 2.0.

Dark Sky Technology defends America’s most critical systems from hidden threats in open-source software. Their platform, Bulletproof Trust, gives defense contractors and government agencies confidence in the integrity of their code by analyzing every risk vector:

• Contributors (who touched it)
• Vulnerabilities (what’s exposed)
• Licenses (what’s legal)
• Maintainability, code quality, and hygiene (what’s operationally dangerous)

Why We Partnered

Trust needs proof. Dark Sky independently evaluated wolfSSL using their TrustScore engine. Results:

• 0 sanctioned contributors
• No license conflicts or IP landmines
• Clean, maintainable code
• No embedded secrets or repo risk

You can view our TrustScore and full transparency report here: Dark Sky TrustScore for wolfSSL.

Why It Matters

For defense, software trust is mandatory. You must know what your code does—and who touched it.

wolfSSL delivers certifiable crypto.
Dark Sky proves its provenance.

No guesswork. No compromise. Just trusted software—by design.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now