RECENT BLOG NEWS

The latest updates to the Espressif-specific integration of wolfSSL bring a significant enhancement for developers working on memory-constrained embedded systems: support for using PSRAM (pseudo-static RAM) during wolfSSL heap operations.

This improvement not only unlocks larger memory capacity for cryptographic operations, but also lays the foundation for more stable and scalable TLS communication on ESP32 and other Espressif-based platforms.

Why more stable?

Some of the ESP32 chip types have relatively little RAM. Once a large and complex application is written, there may be little leftover room for TLS exchanges. Heap corruption and / or stack overflows will typically ensue, causing undesired stability problems.

What Changed?

The recent GitHub Pull Request #8987 introduces a set of enhancements that allow dynamic memory allocation routines in wolfSSL to take advantage of the extended PSRAM region (when available). This is especially valuable on platforms such as the ESP32-WROVER, ESP32-C3, and ESP32-S3 which support external PSRAM.

Here’s a breakdown of the key updates:

Custom Allocator Integration

wolfSSL can now check for application-defined memory allocators using wolfSSL_GetAllocators() before falling back to the default FreeRTOS pvPortMalloc() or realloc() calls. This opens up new flexibility.

For instance, add these #define statements to the wolfssl user_settings.h file.

#define XMALLOC_USER
#define XFREE MY_FREE
#define XMALLOC MY_MALLOC

Then implement custom FREE and MALLOC in the application.

void MY_FREE(void *p, void* heap, int type)
{
    free(p);
}

void* MY_MALLOC(size_t sz, void* heap, int type)
{
    return malloc(sz);
}

With this mechanism, if your app defines a heap allocator that maps to PSRAM (e.g., via heap_caps_malloc(…, MALLOC_CAP_SPIRAM)), wolfSSL will use it.

XREALLOC / XMALLOC / XFREE Wrappers Updated

Custom memory macros (XMALLOC, XFREE, XREALLOC) were updated to redirect to the new PSRAM-aware versions in esp_sdk_mem_lib.c. Debug versions were added as well:

#define XMALLOC(s, h, type) \
    wc_pvPortMalloc((s)) // Uses PSRAM-aware allocator

Debug-Friendly Memory Tracing

For developers debugging memory usage, verbose allocation logging was added when either DEBUG_WOLFSSL or DEBUG_WOLFSSL_MALLOC are defined. This makes it easier to catch leaks, misallocations, or fragmentation in systems where memory is limited.

ESP_LOGE("malloc", "Failed Allocating memory of size: %d bytes", size);

Benefits of PSRAM Integration

Embedded systems often face memory limitations, especially when running TLS sessions, parsing certificates, or handling large buffers. By enabling PSRAM usage in wolfSSL:

• Larger TLS Buffers: Allows larger I/O buffers and longer certificate chains without heap exhaustion.
• Stronger Security: Enables features like TLS 1.3 with minimal compromise on memory availability.
• Scalability: Supports more simultaneous connections or sessions on memory-constrained MCUs.
• Debugging Support: Optional debug builds can now track allocations and reallocation failures with file/line/function info.

How to Enable It

This integration is automatic if you’re using wolfSSL on ESP-IDF and PSRAM is configured in your project.

For full benefit:

Ensure your build enables PSRAM via menuconfig:
Component config – ESP32-specific – Support for external – SPI-connected RAM

Optionally implement custom allocators using heap_caps_malloc() targeting PSRAM:

void* my_malloc(size_t sz) {
    return heap_caps_malloc(sz, MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);
}

Register your allocators:

wolfSSL_SetAllocators(my_malloc, my_free, my_realloc);

As a reminder: No more than CONFIG_LWIP_MAX_SOCKETS sockets should be opened.

Example:

#ifndef NO_WOLFSSL_MEMORY
static void *custom_malloc(size_t size) {
    void* this_custom_malloc;
    this_custom_malloc = heap_caps_malloc(size, MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);
    return this_custom_malloc;
}

static void* custom_realloc(void* ptr, size_t size) {
    void* this_custom_realloc;
    this_custom_realloc = heap_caps_realloc(ptr, size, MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT);
    return this_custom_realloc;
}

static void custom_free(void *ptr) {
    heap_caps_free(ptr);
}
#endif

Then in the main app, use wolfSSL_SetAllocators:

#if defined(NO_WOLFSSL_MEMORY)
    ESP_LOGE(TAG, "Cannot use wolfSSL_SetAllocators with NO_WOLFSSL_MEMORY");
#else
    wolfSSL_SetAllocators((wolfSSL_Malloc_cb)custom_malloc,
                          (wolfSSL_Free_cb)custom_free,
                          (wolfSSL_Realloc_cb)custom_realloc);
#endif

    esp_err_t error = heap_caps_register_failed_alloc_callback(heap_caps_alloc_failed_hook);
    if (error == ESP_OK) {
        ESP_LOGE(TAG, "Success: heap_caps_register_failed_alloc_callback");
    }
    else {
        ESP_LOGE(TAG, "FAILED: heap_caps_register_failed_alloc_callback");
    }

Tested Platforms

This change is specifically tailored for the Espressif ESP-IDF platform, including:

• ESP32-WROVER
• ESP32-S3
• ESP32-C3 (with PSRAM)
• Any module with external SPI RAM

Acknowledgements

We extend our thanks to Fidel for suggesting, contributing sample code, and helping to test this feature. Congratulations on getting 50 concurrent FreeRTOS tasks running on the ESP32, each communicating with wolfSSL Post Quantum algorithms!

Ing. Fidel Alejandro Rodríguez Corbo, Phd
Smart Electronics Research Group
School of Engineering and Science
Tecnologico de Monterrey,
Av. Eugenio Garza Sada 2501 Sur
Col. Tecnológico, C.P. 64849
Monterrey, Nuevo León, México

Final Thoughts

This patch brings wolfSSL one step closer to optimal memory use in constrained environments. By supporting PSRAM, developers can offload cryptographic operations away from limited internal RAM – enhancing both stability and performance.

wolfSSL continues to push forward in embedded TLS innovation, and these improvements make it an even better fit for secure IoT applications on ESP32.

For more information or to contribute, visit wolfSSL GitHub and explore the Espressif-specific README.

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

We’re excited to announce that wolfSSL v5.8.2 is now officially released and available through The ESP Component Registry!

wolfSSL is a lightweight, high-performance TLS/SSL library optimized for embedded systems. It is widely used in IoT, automotive, aerospace, and other resource-constrained environments.

What’s New in v5.8.2:

• Security Enhancements: Multiple updates for improved cryptographic robustness and protocol handling.
• Expanded Hardware Acceleration Support: Optimizations for ESP32 and ESP32-C3/C6/S3 targets, making the most of Espressif’s hardware crypto engines.
• Improved Certificate Handling: More flexible certificate loading and verification, including enhancements for embedded CA chains.
• Bug Fixes and Stability Improvements: Various fixes across TLS 1.2 and TLS 1.3 implementations to ensure smoother and more reliable secure connections.
• ESP-IDF Compatibility: Verified support for ESP-IDF v5.x, ensuring seamless integration with the latest Espressif SDKs.

Check out the wolfSSL release notes!

Why Use wolfSSL on ESP32?

• Minimal footprint with aggressive size optimizations.
• Full support for TLS 1.3 and TLS 1.2.
• Hardware crypto acceleration using Espressif APIs.
• FIPS-ready and MISRA-compliant options available for safety-critical applications.

Integration Highlights

• Register and include the component in your

  idf_component.yml:
  dependencies:
    wolfssl/wolfssl:
      version: "5.8.2"
  

• Or install via the command line:

  idf.py add-dependency "wolfssl/wolfssl@5.8.2"
  

Get Started With Examples

To help you get started quickly, the wolfSSL v5.8.2 component includes a rich set of fully integrated ESP-IDF examples, covering a variety of use cases and configurations.

1. setup the ESP-IDF environment.
2. fetch the wolfSSL benchmark example.
3. change directory to the downloaded project.
4. compile, upload, and view output.

Like this:

. ~/esp/esp-idf/export.sh

idf.py create-project-from-example "wolfssl/wolfssl^5.8.2:wolfssl_test"

cd wolfssl_test

idf.py -b 115200 flash monitor

These examples are ideal for developers new to wolfSSL, as well as those looking to evaluate specific TLS features or test hardware acceleration support on Espressif chips.

• template A minimally viable wolfSSL setup, perfect as a starting point for your own project. This clean and simple example helps you integrate wolfSSL with minimal configuration.
• wolfssl_benchmark – Runs the wolfcrypt benchmark application on your ESP32 target. Ideal for measuring the performance of cryptographic operations across different chips and configurations.
• wolfssl_client – A TLS client demo that connects to a secure server (e.g., CLI server or Espressif TLS server). Demonstrates how to initialize, configure, and run a secure client using wolfSSL.
• wolfssl_server – A TLS server counterpart to the client example. This demo creates a secure endpoint on the ESP32 and shows how to handle TLS handshakes and encrypted communications.
• wolfssl_test – A port of the wolfcrypt test application for ESP32. Use this to verify the build and runtime functionality of various wolfSSL cryptographic components in your environment.

New to wolfSSL on the Espressif family of devices?

If you are new to wolfSSL on the Espressif ESP32, this video can help to get started:

Additional Details

To check which version of the Component Manager is currently available, use the command:

python -m idf_component_manager -h

The Component Manager should have been installed during the installation of the ESP-IDF. If your version of ESP-IDF doesn’t come with the IDF Component Manager, you can install it:

python -m pip install --upgrade 
idf-component-manager

For further details on the Espressif Component Manager, see the GitHub idf-component-manager repo.

Have a specific request or questions? We’d love to hear from you. Please contact us at support@wolfssl.com or open an issue on GitHub.

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

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