Convert Figma logo to code with AI

wolfSSL logowolfssl

The wolfSSL library is a small, fast, portable implementation of TLS/SSL for embedded devices to the cloud. wolfSSL supports up to TLS 1.3 and DTLS 1.3!

2,650
902
2,650
145
View on GitHub

Top Related Projects

openssl's avatar

openssl

28,995

TLS/SSL and crypto library

Mbed-TLS's avatar

mbedtls

6,257

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.

libressl's avatar

portable

1,438

LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code. Pull requests or patches sent to tech@openbsd.org are welcome.

google's avatar

boringssl

2,048

Mirror of BoringSSL

aws's avatar

s2n-tls

4,650

An implementation of the TLS/SSL protocols

indutny's avatar

elliptic

1,755

Fast Elliptic Curve Cryptography in plain javascript

Quick Overview

wolfSSL is a lightweight, portable, C-language-based SSL/TLS library targeted for embedded, RTOS, and resource-constrained environments. It's a popular choice for IoT, automotive, and enterprise security applications due to its small footprint, speed, and extensive feature set.

Pros

  • Small footprint (20-100 kB) ideal for embedded systems
  • Fast performance, optimized for speed and efficiency
  • Extensive platform support, including various RTOS and embedded systems
  • Strong security features, including support for the latest TLS 1.3 protocol

Cons

  • Less extensive documentation compared to some larger SSL/TLS libraries
  • Smaller community compared to OpenSSL
  • Some advanced features may require a commercial license
  • Learning curve for developers new to embedded SSL/TLS implementations

Code Examples

  1. Initializing wolfSSL:
#include <wolfssl/ssl.h>

int ret = wolfSSL_Init();
if (ret != WOLFSSL_SUCCESS) {
    // Error handling
}
  1. Creating a wolfSSL context:
WOLFSSL_CTX* ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
if (ctx == NULL) {
    // Error handling
}
  1. Establishing a secure connection:
WOLFSSL* ssl = wolfSSL_new(ctx);
if (ssl == NULL) {
    // Error handling
}

wolfSSL_set_fd(ssl, sockfd);
int ret = wolfSSL_connect(ssl);
if (ret != WOLFSSL_SUCCESS) {
    // Error handling
}

Getting Started

To get started with wolfSSL:

  1. Download the wolfSSL source from GitHub:

    git clone https://github.com/wolfSSL/wolfssl.git

  2. Configure and build the library:

    cd wolfssl
./autogen.sh
./configure
make
sudo make install

  3. Include wolfSSL in your project:

    #include <wolfssl/ssl.h>

  4. Link against the wolfSSL library when compiling:

    gcc -o your_program your_program.c -lwolfssl

Remember to initialize wolfSSL with wolfSSL_Init() at the beginning of your program and clean up with wolfSSL_Cleanup() at the end.

Competitor Comparisons

openssl logo

openssl

28,995

TLS/SSL and crypto library

Pros of OpenSSL

  • Extensive feature set and wide protocol support
  • Large community and extensive documentation
  • Broad platform compatibility and hardware acceleration support

Cons of OpenSSL

  • Larger codebase and memory footprint
  • More complex API and steeper learning curve
  • Slower release cycle for updates and patches

Code Comparison

OpenSSL example (TLS client):

SSL_CTX *ctx = SSL_CTX_new(TLS_client_method());
SSL *ssl = SSL_new(ctx);
SSL_set_fd(ssl, socket);
SSL_connect(ssl);

wolfSSL example (TLS client):

WOLFSSL_CTX* ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
WOLFSSL* ssl = wolfSSL_new(ctx);
wolfSSL_set_fd(ssl, socket);
wolfSSL_connect(ssl);

Both libraries offer similar APIs, but wolfSSL tends to have a more streamlined interface. OpenSSL provides more configuration options, while wolfSSL focuses on a smaller, more efficient codebase. OpenSSL is more widely adopted and has broader protocol support, whereas wolfSSL is designed for embedded systems and resource-constrained environments, offering a smaller footprint and faster performance in many cases.

Mbed-TLS logo

mbedtls

6,257

An open source, portable, easy to use, readable and flexible TLS library, and reference implementation of the PSA Cryptography API. Releases are on a varying cadence, typically around 3 - 6 months between releases.

Pros of Mbed TLS

  • More extensive documentation and examples
  • Broader platform support, including bare-metal environments
  • Easier integration with ARM-based systems and IoT devices

Cons of Mbed TLS

  • Generally slower performance compared to wolfSSL
  • Larger code size and memory footprint
  • Less frequent updates and slower adoption of new standards

Code Comparison

Mbed TLS initialization:

#include "mbedtls/ssl.h"

mbedtls_ssl_context ssl;
mbedtls_ssl_config conf;

mbedtls_ssl_init(&ssl);
mbedtls_ssl_config_init(&conf);

wolfSSL initialization:

#include <wolfssl/ssl.h>

WOLFSSL_CTX* ctx;
WOLFSSL* ssl;

ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
ssl = wolfSSL_new(ctx);

Both libraries offer similar APIs for SSL/TLS functionality, but wolfSSL tends to have a more streamlined approach with fewer function calls required for basic setup. Mbed TLS provides more granular control over configuration options, which can be beneficial for complex scenarios but may require more code for simple use cases.

libressl logo

portable

1,438

LibreSSL Portable itself. This includes the build scaffold and compatibility layer that builds portable LibreSSL from the OpenBSD source code. Pull requests or patches sent to tech@openbsd.org are welcome.

Pros of LibreSSL

  • More comprehensive and feature-rich, offering a wider range of cryptographic functions
  • Better compatibility with OpenSSL, making it easier to integrate into existing systems
  • More active development and frequent updates

Cons of LibreSSL

  • Larger codebase and memory footprint, which may not be ideal for embedded systems
  • Potentially slower performance due to its more extensive feature set
  • Less focus on small-scale or resource-constrained environments

Code Comparison

LibreSSL:

SSL_CTX *ctx = SSL_CTX_new(TLS_method());
SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION);
SSL_CTX_set_max_proto_version(ctx, TLS1_3_VERSION);

wolfSSL:

WOLFSSL_CTX* ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
wolfSSL_CTX_SetMinVersion(ctx, WOLFSSL_TLSV1_2);
wolfSSL_CTX_SetMaxVersion(ctx, WOLFSSL_TLSV1_3);

Both libraries provide similar functionality for creating SSL contexts and setting protocol versions. However, LibreSSL's API more closely resembles OpenSSL, while wolfSSL uses its own naming conventions.

google logo

boringssl

2,048

Mirror of BoringSSL

Pros of BoringSSL

  • Developed and maintained by Google, benefiting from their extensive resources and expertise
  • Designed for performance and efficiency in modern systems
  • Regularly updated with the latest security patches and improvements

Cons of BoringSSL

  • Less flexible and customizable compared to wolfSSL
  • Not as widely supported across different platforms and architectures
  • May have a steeper learning curve for developers unfamiliar with Google's coding practices

Code Comparison

wolfSSL:

int wolfSSL_CTX_use_certificate_file(WOLFSSL_CTX* ctx, const char* file,
                                     int format)
{
    WOLFSSL_ENTER("wolfSSL_CTX_use_certificate_file");
    return ProcessFile(ctx, file, format, CERT_TYPE, NULL, 0, NULL);
}

BoringSSL:

int SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file, int type) {
  BIO *in;
  int ret = 0;
  X509 *x = NULL;

  in = BIO_new(BIO_s_file());
  if (in == NULL) {
    OPENSSL_PUT_ERROR(SSL, ERR_R_BUF_LIB);
    goto end;
  }

Both libraries provide similar functionality for loading certificates, but BoringSSL's implementation is more verbose and includes additional error handling.

aws logo

s2n-tls

4,650

An implementation of the TLS/SSL protocols

Pros of s2n-tls

  • Designed specifically for AWS services, offering seamless integration with AWS infrastructure
  • Focused on simplicity and minimal code base, potentially reducing the attack surface
  • Regularly audited and maintained by AWS, ensuring high security standards

Cons of s2n-tls

  • Limited to TLS 1.2 and 1.3, lacking support for older protocols
  • Fewer cryptographic algorithms and features compared to wolfSSL
  • Less flexibility for customization and integration with non-AWS systems

Code Comparison

s2n-tls:

s2n_config *config = s2n_config_new();
s2n_connection *conn = s2n_connection_new(S2N_CLIENT);
s2n_connection_set_config(conn, config);
s2n_negotiate(conn, &blocked);

wolfSSL:

WOLFSSL_CTX* ctx = wolfSSL_CTX_new(wolfTLSv1_2_client_method());
WOLFSSL* ssl = wolfSSL_new(ctx);
wolfSSL_connect(ssl);
wolfSSL_write(ssl, message, strlen(message));

Both libraries offer straightforward APIs for establishing TLS connections, but s2n-tls focuses on AWS-specific use cases, while wolfSSL provides a more general-purpose solution with broader protocol support and customization options.

indutny logo

elliptic

1,755

Fast Elliptic Curve Cryptography in plain javascript

Pros of elliptic

  • Lightweight and focused specifically on elliptic curve cryptography
  • Easier to integrate into JavaScript/Node.js projects
  • More active community contributions and frequent updates

Cons of elliptic

  • Limited to elliptic curve operations, not a full cryptographic suite
  • Less comprehensive documentation compared to wolfSSL
  • May have lower performance for certain operations on some platforms

Code Comparison

elliptic:

const EC = require('elliptic').ec;
const ec = new EC('secp256k1');
const key = ec.genKeyPair();
const signature = key.sign(msgHash);
console.log(signature.toDER('hex'));

wolfSSL:

#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/ecc.h>

ecc_key key;
wc_ecc_init(&key);
wc_ecc_make_key(&rng, 32, &key);
wc_ecc_sign_hash(hash, hashLen, signature, &sigLen, &rng, &key);

wolfSSL offers a more comprehensive cryptographic library with support for various algorithms and protocols, while elliptic focuses specifically on elliptic curve operations. elliptic is more suitable for JavaScript-based projects, whereas wolfSSL is better for C/C++ applications requiring a full-featured cryptographic suite.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

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:

  • WOLFSSL_STATIC_DH
  • WOLFSSL_STATIC_RSA
  • WOLFSSL_STATIC_PSK

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 ssl.c, wolfSSL will now issue a compiler error if no cipher suites are available. You can remove this error by defining WOLFSSL_ALLOW_NO_SUITES in the event that you desire that, i.e., you're not using TLS cipher suites.

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 SSL_connect succeed even if verifying the server fails and reducing security you can do this by calling:

wolfSSL_CTX_set_verify(ctx, WOLFSSL_VERIFY_NONE, NULL);

before calling wolfSSL_new();. Though it's not recommended.

Note 3

The enum values SHA, SHA256, SHA384, SHA512 are no longer available when wolfSSL is built with --enable-opensslextra (OPENSSL_EXTRA) or with the macro NO_OLD_SHA_NAMES. These names get mapped to the OpenSSL API for a single call hash function. Instead the name WC_SHA, WC_SHA256, WC_SHA384 and WC_SHA512 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] Signature Algorithm downgrade from ECDSA P521 to P256 during TLS 1.3 handshake. When a client sends ECDSA P521 as the supported signature algorithm the server previously could respond as ECDSA P256 being the accepted signature algorithm and the connection would continue with using ECDSA P256. Thanks to Jaehun Lee from Pohang University of Science and Technology (POSTECH) for the report. Fixed in PR 9113.

  • [Low CVE-2025-11933] DoS Vulnerability in wolfSSL TLS 1.3 CKS extension parsing. Previously duplicate CKS extensions were not rejected leading to a potential memory leak when processing a ClientHello. Thanks to Jaehun Lee from Pohang University of Science and Technology (POSTECH) for the report. Fixed in PR 9132.

  • [Low CVE-2025-11931] Integer Underflow Leads to Out-of-Bounds Access in XChaCha20-Poly1305 Decrypt. This issue is hit specifically with a call to the function wc_XChaCha20Poly1305_Decrypt() which is not used with TLS connections, only from direct calls from an application. Thanks to Luigino Camastra from Aisle Research for the report. Fixed in PR 9223.

  • [Low CVE-2025-11932] Timing Side-Channel in PSK Binder Verification. The server previously verified the TLS 1.3 PSK binder using a non-constant time method which could potentially leak information about the PSK binder. Thanks to Luigino Camastra from Aisle Research for the report. Fixed in PR 9223.

  • [Low CVE-2025-12889] With TLS 1.2 connections a client can use any digest, specifically a weaker digest, rather than those in the CertificateRequest. Thanks to Jaehun Lee from Pohang University of Science and Technology (POSTECH) for the report. Fixed in PR 9395

  • [Low CVE-2025-13912] When using the Clang compiler, various optimization levels or flags could result in non-constant-time compiled code. Assembly implementations of the functions in wolfSSL were not affected. The report was done specifically with Clang version 18 but there was shown to be similarities in timing variations when using the optimization levels with Clang 14 and Clang 20.

On the following architectures, the expected constant-time functions were found to have potential timing variations when specific compiler flags or optimization levels were used.

AArch64: Using O3, Ofast, or --enable-nontrivial-unswitch with O1/O2 flags leads to possible timing variations with the software implementations of sp_read_radix, sp_div_2_mod_ct, and sp_addmod_ct. Using O3, O2, Ofast, Os, or Oz with --unroll-force-peel-count=50 leads to possible timing variations with wc_AesGcmDecrypt.

RISC-V: TLS HMAC update/final operations, RSA unpad operations, and DH key pair generation with O1, O2, O3, Ofast, Oz, or Os. wc_AesGcmDecrypt and wc_Chacha_Process with O1, O2, O3, Os, or Ofast. Also SP software operations sp_div_2_mod_ct and sp_addmod_ct using O3 or Ofast.

X86_64: TLS HMAC update/final operations and TimingVerifyPad used with verifying the TLS MAC with --fast-isel or --x86-cmov-converter-force-all compile flags. RSA unpad operations, ECC mulmod, and wc_Chacha_Process with the --x86-cmov-converter-force-all flag. DH key agreement, sp_div_2_mod_ct and sp_addmod_ct with O1, O2, O3, Os, or Ofast. wc_AesGcmDecrypt with the compiler flags O2, O3, Os, Ofast, Oz --x86-cmov-converter-force-all | --unroll-force-peel-count=50, or O1 --x86-cmov-converter-force-all.

Thanks to Jing Liu, Zhiyuan Zhang, LUCÍA MARTÍNEZ GAVIER, Gilles Barthe, Marcel Böhme from Max Planck Institute for Security and Privacy (MPI-SP) for the report. Fixed in PR 9148.

New Features

  • New ML-KEM / ML-DSA APIs and seed/import PKCS8 support; added _new/_delete APIs for ML-KEM/ML-DSA. (PR 9039, 9000, 9049)
  • Initial wolfCrypt FreeBSD kernel module support (PR 9392)
  • Expanded PKCS7/CMS capabilities: decode SymmetricKeyPackage / OneSymmetricKey, add wc_PKCS7_GetEnvelopedDataKariRid, and allow PKCS7 builds with AES keywrap unset. (PR 9018, 9029, 9032)
  • Add custom AES key wrap/unwrap callbacks and crypto callback copy/free operations. (PR 9002, 9309)
  • Add support for certificate_authorities extension in ClientHello and certificate manager CA-type selection/unloading. (PR 9209, 9046)
  • Large expansion of Rust wrapper modules: random, aes, rsa, ecc, dh, sha, hmac, cmac, ed25519/ed448, pbkdf2/PKCS#12, kdf/prf, SRTP KDFs, and conditional compilation options. (PR 9191, 9212, 9273, 9306, 9320, 9328, 9368, 9389, 9357, 9433)
  • Rust: support optional heap and dev_id parameters and enable conditional compilation based on C build options. (PR 9407, 9433)
  • STM32 fixes (benchmarking and platform fixes) and PSoC6 hardware acceleration additions. (PR 9228, 9256, 9185)
  • STM32U5 added support for SAES and DHUK. (PR 9087)
  • Add --enable-curl=tiny option for a smaller build when used with cURL. (PR 9174)

Improvements / Optimizations

  • Regression test fixes and expansion: TLS 1.3/1.2 tests, ARDUINO examples, libssh2 tests, hostap workflows, and nightly test improvements. (PR 9096, 9141, 9091, 9122, 9388)
  • Improved test ordering and CI test stability (random tests run order changes, FIPS test fixes). (PR 9204, 9257)
  • Docs and readme fixes, docstring updates, AsconAEAD comment placement, and example certificate renewals. (PR 9131, 9293, 9262, 9429)
  • Updated GPL exception lists (GPLv2 and GPLv3 exception updates: add Fetchmail and OpenVPN). (PR 9398, 9413)
  • Introduced WOLFSSL_DEBUG_CERTS and additional debug/logging refinements. (PR 8902, 9055)
  • Expanded crypto-callback support (SHA family, HKDF, SHA-224, sha512_family digest selection) and improved crypto-only build cases. (PR 9070, 9252, 9271, 9100, 9194)
  • AES & HW offload improvements including AES-CTR support in PKCS11 driver and AES ECB offload sizing fix. (PR 9277, 9364)
  • ESP32: PSRAM allocator support and SHA HW fixes for ESP-IDF v6/v5. (PR 8987, 9225, 9264)
  • Renesas FSP / RA examples updated and security-module TLS context improvements. (PR 9047, 9010, 9158, 9150)
  • Broad configure/CMake/Autotools workflow improvements (Apple options tracking, Watcom pinning, Debian packaging, ESP-IDF pinning). (PR 9037, 9167, 9161, 9264)
  • New assembly introspection / performance helpers for RISC-V and PPC32; benchmarking enhancements (cycle counts). (PR 9101, 9317)
  • Update to SGX build for using assembly optimizations. (PR 8463, 9138)
  • Testing with Fil-C compiler version to 0.674 (PR 9396)
  • Refactors and compressing of small stack code (PR 9153)

Bug Fixes

  • Removed the test feature using popen when defining the macro WOLFSSL_USE_POPEN_HOST and not having HAVE_GETADDRINFO defined, along with having the macro HAVE_HTTP_CLIENT set. There was the potential for vulnerable behavior with the use of popen when the API wolfSSL_BIO_new_connect() was called with this specific build. This exact build configuration is only intended for testing with QEMU and is not enabled with any autoconf/cmake flags. Thanks to linraymond2006 for the report. (PR 9038)
  • Fix for C# wrapper Ed25519 potential crash and heap overwrite with raw public key import when using the API Ed25519ImportPublic.This was a broken API with the C# wrapper that would crash on use. Thanks to Luigino Camastra from Aisle Research for the bug report. (PR 9291)
  • Coverity, cppcheck, MISRA, clang-tidy, ZeroPath and other static-analysis driven fixes across the codebase. (PR 9006, 9078, 9068, 9265, 9324)
  • TLS 1.2/DTLS improvements: client message order checks, DTLS cookie/exchange and replay protections, better DTLS early-data handling. (PR 9387, 9253, 9205, 9367)
  • Improved X.509 & cert handling: allow larger pathLen in Basic Constraints, restore inner server name for ECH, retrying cert candidate chains. (PR 8890, 9234, 8692)
  • Sniffer robustness: fix infinite recursion, better handling of OOO appData and partial overlaps, and improved retransmission detection. (PR 9051, 9106, 9140, 9094)
  • Numerous linuxkm (kernel-mode) fixes, relocation/PIE normalization, and FIPS-related build tweaks across many iterations. (PR 9025, 9035, 9067, 9111, 9121)
  • ML-KEM/Kyber and ML-DSA fixes for out-of-bounds and seed-import correctness; multiple ML-related safety fixes. (PR 9142, 9105, 9439)
  • Avoid uninitialized-variable and GCC warnings; several fixes for undefined-shift/overflow issues. (PR 9020, 9372, 9195)
  • Memory & leak fixes in X509 verification and various struct sizing fixes for WOLFSSL_NO_MALLOC usage. (PR 9258, 9036)
  • Fixed RSA / signing / verify-only warnings allowing WOLFSSL_NO_CT_OPS when WOLFSSL_RSA_VERIFY_ONLY is used and API cleanups for using const. (PR 9031, 9263)

For additional vulnerability information visit the vulnerability page at: https://www.wolfssl.com/docs/security-vulnerabilities/

See INSTALL file for build instructions. More info can be found on-line at: https://wolfssl.com/wolfSSL/Docs.html

Resources

wolfSSL Website

wolfSSL Wiki

FIPS 140-2/140-3 FAQ

wolfSSL Documentation

wolfSSL Manual

wolfSSL API Reference

wolfCrypt API Reference

TLS 1.3

wolfSSL Vulnerabilities

Additional wolfSSL Examples

Directory structure

<wolfssl_root>
├── certs   [Certificates used in tests and examples]
├── cmake   [Cmake build utilities]
├── debian  [Debian packaging files]
├── doc     [Documentation for wolfSSL (Doxygen)]
├── Docker  [Prebuilt Docker environments]
├── examples    [wolfSSL examples]
│   ├── asn1    [ASN.1 printing example]
│   ├── async   [Asynchronous Cryptography example]
│   ├── benchmark   [TLS benchmark example]
│   ├── client  [Client example]
│   ├── configs [Example build configurations]
│   ├── echoclient  [Echoclient example]
│   ├── echoserver  [Echoserver example]
│   ├── pem [Example for convert between PEM and DER]
│   ├── sctp    [Servers and clients that demonstrate wolfSSL's DTLS-SCTP support]
│   └── server  [Server example]
├── IDE     [Contains example projects for various development environments]
├── linuxkm [Linux Kernel Module implementation]
├── m4      [Autotools utilities]
├── mcapi   [wolfSSL MPLAB X Project Files]
├── mplabx  [wolfSSL MPLAB X Project Files]
├── mqx     [wolfSSL Freescale CodeWarrior Project Files]
├── rpm     [RPM packaging metadata]
├── RTOS
│   └── nuttx   [Port of wolfSSL for NuttX]
├── scripts [Testing scripts]
├── src     [wolfSSL source code]
├── sslSniffer  [wolfSSL sniffer can be used to passively sniff SSL traffic]
├── support [Contains the pkg-config file]
├── tests   [Unit and configuration testing]
├── testsuite   [Test application that orchestrates tests]
├── tirtos  [Port of wolfSSL for TI RTOS]
├── wolfcrypt   [The wolfCrypt component]
│   ├── benchmark   [Cryptography benchmarking application]
│   ├── src         [wolfCrypt source code]
│   │   └── port    [Supported hardware acceleration ports]
│   └── test        [Cryptography testing application]
├── wolfssl [Header files]
│   ├── openssl [Compatibility layer headers]
│   └── wolfcrypt   [Header files]
├── wrapper [wolfSSL language wrappers]
└── zephyr  [Port of wolfSSL for Zephyr RTOS]