Category: wolfSSL/ wolfCrypt

Ensuring your TLS certificates are still valid and haven’t been revoked is critical for secure communications. Two methods exist for this:

Certificate Revocation Lists (CRLs) are signed lists published by Certificate Authorities that clients download and check offline. They contain serial numbers of revoked certificates and must be regularly updated and cached by clients to remain effective. CRLs are simple and privacy-friendly but can become large over time and may not reflect revocations in real-time, leaving a window of vulnerability between updates.

Online Certificate Status Protocol (OCSP) lets clients query a CA’s responder in real-time to check if a certificate is revoked. It provides up-to-date, on-demand validation with lower bandwidth than downloading full CRLs. However, it requires an active network connection and can introduce latency or privacy concerns if the client queries the CA directly. OCSP Stapling addresses these issues by allowing the server to “staple” a recent OCSP response to the TLS handshake, improving performance and protecting client privacy.

wolfSSL supports both CRL and OCSP checking, plus OCSP stapling, giving you flexible, layered certificate validation that fits any use case. Enable CRL support to verify certificates against cached revocation lists, and OCSP for live, up-to-the-minute status checks. Use both together for maximum security—CRLs handle offline or initial checks, and OCSP keeps your system aware of recent revocations.

In wolfSSL, enabling these features is straightforward:

// Enable and load CRL
wolfSSL_CTX_EnableCRL(ctx, WOLFSSL_CRL_CHECKALL);
wolfSSL_CTX_LoadCRL(ctx, "crl.pem", WOLFSSL_FILETYPE_PEM, 0);

// Enable OCSP checking and stapling
wolfSSL_CTX_EnableOCSP(ctx, WOLFSSL_OCSP_CHECKALL);
wolfSSL_CTX_EnableOCSPStapling(ctx);

Check out our manual for more information on these APIs:

• function wolfSSL_CTX_EnableCRL
• function wolfSSL_CTX_EnableOCSP

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

Most TLS libraries leave your certificates and private keys sitting in RAM long after they’re used — a jackpot for attackers with memory access. wolfSSL is the only TLS library that gives you the power to erase them completely with the wolfSSL_UnloadCertsKeys API. This function doesn’t just free memory — it securely zeroes out every byte of your sensitive data, ensuring nothing remains to be stolen.

From IoT devices and payment terminals to aerospace, automotive, and defense systems, wolfSSL_UnloadCertsKeys helps you meet the toughest security and compliance requirements. Combined with wolfSSL’s FIPS 140-3 validated cryptography, you get end-to-end protection: strong encryption for data in transit, and proactive memory sanitization for keys at rest in RAM. This synergy reduces your attack surface, thwarts memory dump attacks, and helps satisfy stringent standards like GDPR, HIPAA, and PCI DSS.

With wolfSSL, you’re not just encrypting traffic — you’re safeguarding the secrets behind it.

You can find more information on the wolfSSL_UnloadCertsKeys API in our manual.

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 deprecating the following:

• WOLFSSL_TLS13_DRAFT preprocessor macro
• –enable-tls13-draft18 configure option

These components were originally introduced during the TLS 1.3 standardization process to support interoperability with implementations based on Draft 18 of the TLS 1.3 specification. During the multi-year standardization process (2014-2018), multiple draft versions were published before the final RFC 8446 was released in August 2018.

The –enable-tls13-draft18 configure option currently has no functional effect in the codebase and serves no purpose.

The WOLFSSL_TLS13_DRAFT macro, when defined, modifies version number handling in TLS handshakes to use draft-specific version numbers (TLS_DRAFT_MAJOR = 0x7f) instead of the final TLS 1.3 version numbers. This was designed to maintain compatibility with implementations during the transition period which ended long ago.

Maintaining compatibility with obsolete specifications introduces unnecessary complexity. The TLS ecosystem has fully migrated to the TLS 1.3 standard. For these reasons, we are eliminating draft compatibility.

This decision is not yet final. If you think you need these configuration flags to be available, please reach out to us at support@wolfssl.com and let us know.

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

Device Identifier Composition Engine (DICE) represents a fairly simple approach to hardware-based device identity and secure boot. DICE creates Cryptographic Device Identities (CDIs) through a blockchain-like verification process, where each boot stage measures the next component and derives unique Compound Device Identifiers using the following formula:

CDI_n = HMAC(CDI_n-1, Hash(program))

CDI_0 = UDS

The formulas mean that each element of the bootchain cryptographically verifies the previous CDI and then generates its new CDI to be passed on to the next stage boot loader. Of course the initial CDI is not a CDI at all, but a UDS (Unique Device Secret). This could be supplied by a PUF (Physically Unclonable Function) but does not need to be; as long as it is unique. wolfHSM is an excellent platform to securely store and sign this secret data. The same process is recursively repeated up the bootchain.

This creates an immutable chain of trust from hardware root secrets through firmware verification, enabling remote attestation and secure key provisioning for IoT devices. The observant reader will note that this differs from a conventional boot chain in that it allows for firmware later in the bootchain to verify the integrity of all the entities in the bootchain before it. Normally, entities in the boot chain only verify software images AFTER them in the boot process.

The specification supports and allows for a plethora of algorithms, notably DICE-compatible algorithms including ECDSA P-256, SHA-256, and Hash DRBG, making it ideal for resource-constrained embedded systems. For system integrators who have minimal binary footprint requirements, wolfCrypt can be built for Bare Metal ARM to support these algorithms within 30KB.

wolfBoot serves as an ideal secure bootloader for DICE-enabled systems, providing memory-efficient firmware authentication and update capabilities. The bootloader’s minimalist design and tiny HAL API also provides secure firmware update mechanisms.

Beyond wolfBoot, custom bootloaders can leverage the same optimized cryptographic implementations to build DICE-compatible secure boot solutions tailored to specific hardware platforms and security requirements.

Are you interested in seeing this work as part of your DICE bootchain? There is no need to wait any longer! Send a message to facts@wolfssl.com to register your interest in DICE with our team and raise the priority in our roadmap for wolfBoot and wolfHSM!

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’s repo pull request #8897 adds significant OpenSSL compatibility layer enhancements across four key areas: RSA operations, big number mathematics, X.509 certificate extensions, and private key serialization.

RSA API Enhancements:

The PR introduces comprehensive RSA-PSS (Probabilistic Signature Scheme) support with enhanced OpenSSL compatibility. Key additions include:

• wolfSSL_EVP_PKEY_CTX_set_rsa_pss_saltlen() for configuring salt lengths
• wolfSSL_EVP_PKEY_CTX_set_rsa_mgf1_md() for setting MGF1 hash algorithms
• wolfSSL_EVP_PKEY_CTX_set_rsa_oaep_md() for RSA-OAEP padding configuration
• The existing wolfSSL_RSA_sign and wolfSSL_RSA_verify functions have been enhanced to support RSA-PSS with custom salt lengths and MGF1 hash types.
• Additional functions include wolfSSL_RSA_padding_add_PKCS1_PSS_mgf1() and wolfSSL_RSA_verify_PKCS1_PSS_mgf1() for advanced PSS padding operations with MGF1 support.

Bignum API Additions:

A new wolfSSL_BN_ucmp() function has been added that compares the absolute values of two WOLFSSL_BIGNUM structures. This function provides OpenSSL-compatible behavior identical to BN_ucmp(). The implementation uses internal duplication to avoid modifying const input parameters, making the implementation compliant with the API.

X.509 Extensions API Additions:

Two X.509 certificate extension handling functions have been added. The wolfSSL_X509v3_get_ext_by_NID() function searches for extensions by their Numeric Identifier (NID) within a stack of extensions, supporting iterative searching with a “lastpos” parameter. The wolfSSL_X509v3_get_ext() function retrieves extensions by index position from an extension stack. Both functions enable programmatic certificate extension processing for PKI applications, policy enforcement, and extension data extraction.

Private Key DER Output API Additions:

The new wolfSSL_i2d_PrivateKey_bio() function provides private key serialization to DER format through BIO objects. This function performs a two-pass operation to determine buffer size and encode the key.

These additions collectively enhance wolfSSL’s OpenSSL compatibility layer, providing essential functionality for RSA-PSS operations, mathematical computations, certificate processing, and key management operations required by modern cryptographic applications.

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

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