RECENT BLOG NEWS

wolfSSL supports the Online Certificate Status Protocol (OCSP) [https://tools.ietf.org/html/rfc2560] as a client and OCSP stapling version 1 [https://tools.ietf.org/html/rfc6066#section-8] and 2 [https://tools.ietf.org/html/rfc6961]. OCSP is a substitute for Certificate Revocation Lists (CRL). CRLs are a list of certificates that shouldn’t be temporarily or permanently trusted. A major setback for CRLs is the time it takes for these lists to propagate. It may take up to a week [https://tools.ietf.org/html/rfc5280#section-3.3] due to CRLs being issued periodically by Certificate Authorities (CA). OCSP allows clients to verify the validity of server certificates with an OCSP responder and know in real time whether to trust a certificate or not.

OCSP stapling is a TLS extension sent by a client that instructs the server that it would like to receive certificate status information. Stapling significantly cuts down on bandwidth and on round trips needed to set up a connection. When a TLS server receives the Certificate Status Request extension from a client, it will transmit the OCSP responders complete, DER-encoded OCSP response. This relieves the client from having to ask an OCSP responder about the certificate validity and saves the OCSP responder bandwidth coming from clients of a frequently visited server.

OCSP stapling version 1 is severely limited by being able to only transmit the status information of only one certificate. Many TLS servers opt to send intermediate certificates along with its own certificate in case clients do not know the intermediate certificate chain. OCSP stapling version 1 will only save the client the trouble of confirming the status of the server’s certificate, but not of checking the intermediate certificates. OCSP stapling version 2 defines a new extension that allows “servers […] to provide status information about not only the server’s own certificate but also the status of intermediate certificates in the chain” [https://tools.ietf.org/html/rfc6961].

To compile wolfSSL with OCSP support, use the following configure options:
OCSP: --enable-ocsp
OCSP stapling: --enable-ocspstapling
OCSP stapling v2: --enable-ocspstapling2

The following API are available in wolfSSL to enable OCSP usage:

int wolfSSL_CTX_EnableOCSP(WOLFSSL_CTX*, int options);
 int wolfSSL_CTX_DisableOCSP(WOLFSSL_CTX*);
 int wolfSSL_CTX_SetOCSP_OverrideURL(WOLFSSL_CTX*, const char*);
 int wolfSSL_CTX_SetOCSP_Cb(WOLFSSL_CTX*,
 CbOCSPIO, CbOCSPRespFree, void*);
 int wolfSSL_CTX_EnableOCSPStapling(WOLFSSL_CTX*);
 int wolfSSL_CTX_DisableOCSPStapling(WOLFSSL_CTX*);
 int wolfSSL_CTX_EnableOCSPMustStaple(WOLFSSL_CTX*);
 int wolfSSL_CTX_DisableOCSPMustStaple(WOLFSSL_CTX*);

The following flow is enough to use OCSP in wolfSSL:

wolfSSL_CTX_EnableOCSP(ctx, 0);

To use OCSP stapling:

wolfSSL_CTX_EnableOCSPStapling(ctx);
 wolfSSL_UseOCSPStapling(ssl, WOLFSSL_CSR_OCSP, 0);
 wolfSSL_CTX_EnableOCSP(ctx, 0);

To use OCSP stapling version 2:

wolfSSL_CTX_EnableOCSPStapling(ctx);
 wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP*, 0);
 wolfSSL_CTX_EnableOCSP(ctx, 0);

* To provide status request information for intermediate certificates use WOLFSSL_CSR2_OCSP_MULTI

To allow the server to provide OCSP stapling responses use:

wolfSSL_CTX_EnableOCSP(ctx, 0);

To provide a custom OCSP responder URL use:

wolfSSL_CTX_SetOCSP_OverrideURL(ctx, ocspUrl);
 wolfSSL_CTX_EnableOCSP(ctx, WOLFSSL_OCSP_URL_OVERRIDE);

OCSP stapling version 2 can’t be used with TLS 1.3 as it has been deprecated [https://tools.ietf.org/html/rfc8446#section-4.4.2.1]. TLS 1.3 uses OCSP stapling version 1 but the certificate status is not a separate message. Instead it is included as an extension to the corresponding certificate.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Support for wolfSSL has been upstreamed to the master OpenVPN branch in f6dca235ae560597a0763f0c98fcc9130b80ccf4! This means that you will be able to use wolfSSL directly in OpenVPN. wolfSSL is a lightweight and embedded SSL/TLS library that is extensively tested to provide the best security available. Using OpenVPN with wolfSSL, you can take advantage of our hardware cryptography and acceleration on many platforms.

To use OpenVPN with wolfSSL:

Compile wolfSSL with:

./configure --enable-openvpn
make
make install

Compile OpenVPN with:

./configure --with-crypto-library=wolfssl
make
make check
make install

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

FIPS 140-2 requires the use of validated cryptography in the security systems implemented by federal agencies to protect sensitive information. The wolfCrypt Module is a comprehensive suite of FIPS Approved algorithms. All key sizes and modes have been implemented to allow flexibility and efficiency.

The National Institute of Standards and Technology (NIST) is sending FIPS cert #2425 into sunset June 2021. For customers who will be impacted, the wolfCrypt Cryptographic Module maintains its #3389 certificate and can be used in conjunction with the wolfSSL embedded SSL/TLS library for full TLS 1.3 client and server support. Upgrade your FIPS cert with wolfSSL to stay afloat and benefit from: 

• Algorithm support for TLS 1.3!
• New algorithms such as AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES
• Hardware encryption support for NXP’s Cryptographic Assistance and Assurance Module (CAAM), NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU), Intel’s AES-NI, and more
• Support for secure elements and TPM’s
• Interoperability with wolfBoot, wolfSSH, and wolfTPM
• Integration support for third party libraries such as strongswan, nginx, python and more

Contact us to upgrade to FIPS cert #3389 at fips@wolfssl.com. 

Additional Resources 

Learn more about wolfSSL support for FIPS cert #3389: https://www.wolfssl.com/wolfcrypt-fips-certificate-3389-3/ 

For a list of supported Operating Environments for wolfCrypt FIPS, check our FIPS page: https://www.wolfssl.com/license/fips/ 

Our FIPS Story

wolfSSL is currently the leader in embedded FIPS certificates. We have a long history in FIPS starting with wolfCrypt FIPS 140-2 Level 1 Certificate #2425 as well as wolfCrypt v4 FIPS 140-2 Level 1 Certificate #3389. wolfSSL partners with FIPS experts KeyPair to bring you FIPS consulting services, and high assurance along each step of your FIPS certification process. Additionally, wolfSSL will be the first implementation of FIPS 140-3.

wolfSSL also provides support for a wolfCrypt FIPS Ready version of the library! wolfCrypt FIPS Ready is our FIPS enabled cryptography layer code included in the wolfSSL source tree that you can enable and build. You do not get a FIPS certificate, you are not FIPS approved, but you will be FIPS Ready. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and power on self test.

wolfCrypt FIPS Ready can be downloaded from the wolfSSL download page located here: https://www.wolfssl.com/download/. More information on getting set up with wolfCrypt FIPS Ready can be found in our FIPS Ready User guide here: https://www.wolfssl.com/docs/fips-ready-user-guide/

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

The wolfSSL library has added support for the cisco/cjose library in version 4.4.0. cjose implements Javascript Object Signing and Encryption (JOSE) in C/C++. JOSE is a framework that allows parties to exchange transfer claims in a secure way. The cjose library has been ported to work with wolfSSL, the best tested crypto library on the market.

To build wolfSSL for cjose:

• ./configure --enable-opensslall --enable-aeskeywrap CPPFLAGS='-DHAVE_EX_DATA -DWOLFSSL_KEY_GEN'
• make
• make install

To build cjose for wolfSSL:

• Download the appropriate patch from https://github.com/wolfSSL/osp/tree/master/cjose. Choose a patch that corresponds or is closest to your version of cjose.
• patch -p1 < <path/to/downloaded/patch>
• autoreconf
• ./configure --with-wolfssl=/usr/local
• make

To verify that this build passes the tests run:

• make check

wolfSSL currently supports cjose version 0.6.1,

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

This feature has been added in commit 0cfde0794b9c5ab1c01171745b800140ee4f8662.

S/MIME is short for Secure/Multipurpose Internet Mail Extensions, a standard for public key encryption and signing of MIME data. The S/MIME standard allows you to sign, authenticate and encrypt plaintext MIME messages. It is commonly used in email. wolfSSL now supports both “enveloped data” (application/pkcs7-mime) and “detached signature” (multipart/signed) messages.

To enable S/MIME support in wolfSSL, run ./configure with the --enable-smime flag, or add HAVE_SMIME to your user_settings.h file. Then, call wolfSSL_SMIME_read_PKCS7() with 2 parameters:

1. A BIO object containing your S/MIME message.
2. A NULL BIO pointer which will be set to the signed data in case of a multipart message.
3. This function call will give you a PKCS7 pointer, or NULL in case of an error.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL  supports Xilinx SoCs and FPGAs. The wolfSSL embedded SSL/TLS library can be used with FPGAs which use the MicroBlaze CPU and/or Zynq and Zynq UltraScale+ SoCs. Improved performance speeds with using the hardware crpyto can be seen. Increasing AES-GCM, RSA, and SHA3 operations performance. In addition to the performance gained a user also gets the additional security the hardware provides while executing the algorithms.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Did you know that you can build Qt 5.12 and 5.13 against the wolfSSL embedded SSL/TLS library instead of the default OpenSSL backend?  Using wolfSSL as a TLS provider in Qt can have many advantages, depending on application and industry.  Some of these may include:

• Progressive TLS protocol support (up to TLS 1.3)
• Smaller footprint size (wolfSSL is up to 20 times smaller than OpenSSL)
• Extensive testing (wolfSSL is the best-tested SSL/TLS implementation available today)
• Certifications (FIPS 140-2 / 140-3, DO-178C)
• Portability (wolfSSL supports over 30 operating systems)
• Hardware cryptography support
• Commercial support
• Consulting services and training available

To compile wolfSSL for Qt, wolfSSL includes a configure option named --enable-qt.  To compile Qt with the wolfSSL, first obtain the Qt patch file from wolfSSL (contact us at facts@wolfssl.com), then follow the steps below:

1. Follow the Building Qt Guide to download needed Qt dependencies and initialize the Qt repository.
2. Change directories into the qt5 directory and checkout a branch between 5.12-5.13.

$ cd qt5
$ git checkout [branch_name]

3. Apply the wolfSSL Qt patch file to qt5.

$ cd qt5/qtbase
$ patch -p1 < /path/to/wolfssl_qt_src.patch

4. Link to wolfSSL directly by setting the WOLFSSL_LIBS variable.

$ export WOLFSSL_LIBS="-L/path/to/wolf-install/lib -lwolfssl"

5. Configure Qt using the “-wolfssl-linked” option, and add wolfSSL header directories to the include path.

$ ./configure -wolfssl-linked -I/path/to/wolf-install/include/wolfssl -I/path/to/wolf-install/include

6. Build Qt.

$ make

7. Test the build.

$ make test

8. Or, run tests individually:

$ qtbase/tests/auto/network/ssl/qsslcertificate/tst_qsslcertificate
$ qtbase/tests/auto/network/ssl/qasn1element/tst_qasn1element
$ qtbase/tests/auto/network/ssl/qpassworddigestor/tst_qpassworddigestor 
$ qtbase/tests/auto/network/ssl/qsslcipher/tst_qsslcipher
$ qtbase/tests/auto/network/ssl/qssldiffiehellmanparameters/tst_qssldiffiehellmanparameters
$ qtbase/tests/auto/network/ssl/qsslellipticcurve/tst_qsslellipticcurve 
$ qtbase/tests/auto/network/ssl/qsslerror/tst_qsslerror 
$ qtbase/tests/auto/network/ssl/qsslkey/tst_qsslkey 
$ qtbase/tests/auto/network/ssl/qsslsocket/tst_qsslsocket
$ qtbase/tests/auto/network/ssl/qsslsocket_onDemandCertificates_member/tst_qsslsocket_onDemandCertificates_member
$ qtbase/tests/auto/network/ssl/qsslsocket_onDemandCertificates_static/tst_qsslsocket_onDemandCertificates_static

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

Did you know that wolfSSL is OS and architecture agnostic, and it can run on bare metal? Did you know that we have DO-178C artifacts for our wolfCrypt software?

The DO-178C wolfCrypt product which is a cryptographic foundation for secure boot and secure firmware update has been integrated and tested with various operating systems including multi-core ARINC 653 compliant Wind River VxWorks 653 and DDC-I’s DO-178C Level A Deos real-time operating system.

You can start using wolfCrypt as an application with ARINC 653 for space and time partitioning in safety-critical avionics real-time operating systems (RTOS).

Let us know if you need help with security for your ARINC 653 requirements. We can make a world of difference for you!

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL provides a robust and secure DTLS 1.2 implementation. During the handshake process, wolfSSL will re-send its previous flight of messages in the following circumstances:

1. a network timeout has occurred waiting on data to arrive for processing
2. the last message of the peer’s current flight has been received out of order
3. a duplicate of the first message of the peer’s current flight has been received

These steps aim to provide a fast and reliable connection process. Unfortunately, the latter two cases may cause wolfSSL to use up more bandwidth than would be necessary for the handshake. If network bandwidth is at a premium for you and you are less worried about latency, then wolfSSL 4.7.0 has introduced a new macro: WOLFSSL_DTLS_RESEND_ONLY_TIMEOUT.

Compile wolfSSL with this macro, either by adding it to your configure command (for example ./configure --enable-dtls CPPFLAGS=-DWOLFSSL_DTLS_RESEND_ONLY_TIMEOUT) or by defining it in your user_setting.h header file. This macro instructs wolfSSL to only re-send its last flight of messages on a network timeout. In practice, wolfSSL will wait longer before re-sending handshake messages so that re-ordered messages get a chance to be processed and duplicate messages don’t trigger re-sends.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

wolfSSL has a major new product in development — wolfSentry, the universal, dynamic, embedded IDPS (intrusion detection and prevention system). At a high level, wolfSentry is a dynamically configurable logic hub, arbitrarily associating user-defined events with user-defined actions, contextualized by connection attributes, tracking the evolution of the client-server relationship. At a low level, wolfSentry is an embedded firewall engine (both static and fully dynamic), with O(log n) lookup of known hosts/netblocks.

wolfSentry will be fully integrated into the wolfSSL library, wolfMQTT, and wolfSSH, with optional in-tree call-ins and callbacks that give application developers turnkey IDPS across all network-facing wolfSSL products, with a viable zero-configuration option. These integrations will be available via simple --enable-wolfidps configure options in wolfSSL sibling products.

The wolfSentry engine will be dynamically configurable programmatically through an API, or from a textual input file supplied to the engine. Callback and client-server implementations will also be supplied that deliver advanced capabilities including remote logging through MQTT or syslog, and remote configuration and status queries, all cryptographically secured.

Notably, wolfSentry is designed from the ground up to function well in resource-constrained, bare-metal, and realtime environments, with algorithms to stay within designated maximum memory footprints and maintain deterministic throughput. Opportunities include RTOS IDPS, and IDPS for ARM silicon and other common embedded CPUs and MCUs. wolfSentry with dynamic firewalling can add as little as 64k to the code footprint, and 32k to the volatile state footprint, and can fully leverage the existing logic and state of applications and sibling libraries.

The first beta release of wolfSentry is planned for April 2021, with turnkey product integrations to follow.

If you have any questions or run into any issues, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.