wolfSSL / wolfssl

wolfSSL Embedded SSL/TLS Library The wolfSSL embedded SSL library (formerly CyaSSL) is a lightweight SSL/TLS library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments - primarily because of its small size, speed, and feature set. It is commonly used in standard operating environments as well because of its royalty-free pricing and excellent cross platform support. wolfSSL supports industry standards up to the current TLS 1.3 and DTLS 1.3, is up to 20 times smaller than OpenSSL, and offers progressive ciphers such as ChaCha20, Curve25519, BLAKE2b/BLAKE2s and Post-Quantum TLS 1.3 groups. User benchmarking and feedback reports dramatically better performance when using wolfSSL over OpenSSL. wolfSSL is powered by the wolfCrypt cryptography library. Two versions of wolfCrypt have been FIPS 140-2 validated (Certificate #2425 and certificate #3389). FIPS 140-3 validated (Certificate #4718). For additional information, visit the wolfCrypt FIPS FAQ or contact fips@wolfssl.com. Why Choose wolfSSL? There are many reasons to choose wolfSSL as your embedded, desktop, mobile, or enterprise SSL/TLS solution. Some of the top reasons include size (typical footprint sizes range from 20-100 kB), support for the newest standards (SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, DTLS 1.0, DTLS 1.2, and DTLS 1.3), current and progressive cipher support (including stream ciphers), multi-platform, royalty free, and an OpenSSL compatibility API to ease porting into existing applications which have previously used the OpenSSL package. For a complete feature list, see Chapter 4 of the wolfSSL manual. Notes, Please Read Note 1 wolfSSL as of 3.6.6 no longer enables SSLv3 by default. By default, wolfSSL disables static key cipher suites that use PSK, RSA, or ECDH without ephemeral key exchange. Instead, wolfSSL enables cipher suites that provide perfect forward secrecy (PFS) using ephemeral Diffie-Hellman (DH) or Elliptic Curve (ECC) key exchange, both of which are enabled by default. If you need to support legacy systems that require static key cipher suites, you can enable them using one or more of these defines: • • • **Important:** Static key cipher suites reduce security by eliminating perfect forward secrecy. These cipher suites reuse the same long-term private key for all session key exchanges. In contrast, PFS-enabled cipher suites (the wolfSSL default) generate a new ephemeral key for each session, ensuring that compromising a long-term key cannot decrypt past sessions. When compiling , wolfSSL will now issue a compiler error if no cipher suites are available. You can remove this error by defining in the event that you desire that, i.e., you're not using TLS cipher suites. AES CryptoCB Key Import Support wolfSSL supports hardware-accelerated AES operations via CryptoCB. When is defined, wolfSSL invokes a CryptoCB callback during AES key setup. The callback behavior determines the mode: **If callback returns 0 (success):** • Key is imported to Secure Element/HSM • Key is NOT copied to wolfSSL RAM (true key isolation) • GCM tables are NOT generated (full hardware offload) • All subsequent AES operations route through CryptoCB **If callback returns CRYPTOCB_UNAVAILABLE:** • SE doesn't support key import • Normal software AES path is used • Key is copied to devKey for CryptoCB encrypt/decrypt acceleration This feature enables TLS 1.3 traffic key protection on embedded platforms where symmetric keys must never exist in main RAM. Enable with: Note 2 wolfSSL takes a different approach to certificate verification than OpenSSL does. The default policy for the client is to verify the server, this means that if you don't load CAs to verify the server you'll get a connect error, no signer error to confirm failure (-188). If you want to mimic OpenSSL behavior of having succeed even if verifying the server fails and reducing security you can do this by calling: before calling . Though it's not recommended. Note 3 The enum values SHA, SHA256, SHA384, SHA512 are no longer available when wolfSSL is built with ( ) or with the macro . These names get mapped to the OpenSSL API for a single call hash function. Instead the name , , and should be used for the enum name. wolfSSL Release 5.8.4 (Nov. 20, 2025) Release 5.8.4 has been developed according to wolfSSL's development and QA process (see link below) and successfully passed the quality criteria. https://www.wolfssl.com/about/wolfssl-software-development-process-quality-assurance NOTE: * --enable-heapmath is deprecated • MD5 is now disabled by default PR stands for Pull Request, and PR references a GitHub pull request number where the code change was added. Vulnerabilities • [Low CVE-2025-12888] Vulnerability in X25519 constant-time cryptographic implementations due to timing side channels introduced by compiler optimizations and CPU architecture limitations, specifically with the Xtensa-based ESP32 chips. If targeting Xtensa it is recommended to use the low memory implementations of X25519, which is now turned on as the default for Xtensa. Thanks to Adrian Cinal for the report. Fixed in PR 9275. • [Med. CVE-2025-11936] Potential DoS vulnerability due to a memory leak through multiple KeyShareEntry with the same group in malicious TLS 1.3 ClientHello messages. This affects users who are running wolfSSL on the server side with TLS 1.3. Thanks to Jaehun Lee and Kyungmin Bae, Pohang University of Science and Technology (POSTECH) for the report. Fixed in PR 9117. • [Low CVE-2025-11935] PSK with PFS (Perfect Forward Secrecy) downgrades to PSK without PFS during TLS 1.3 handshake. If the client sends a ClientHello that has a key share extension and the server responds with a ServerHello that does not have a key share extension the connection would previously continue on without using PFS. Thanks to Jaehun Lee from Pohang University of Science and Technology (POSTECH) for the report. Fixed in PR 9112. • [Low CVE-2025-11934]…