RECENT BLOG NEWS

Thanks to the portability of our wolfCrypt library, plus our team of expert engineers, wolfSSL is frequently adding new ports. Keep an eye out as we continue showcasing a few of the latest open source project ports over the next few weeks!

We have recently integrated wolfSSL with the socat tool for Linux. This port allows for the use of socat with our FIPS-validated crypto library, wolfCrypt. Socat is a command line based utility that allows for bidirectional data transfers between two independent channels. For more information on socat, please visit the project’s website at www.dest-unreach.org/socat. 

As of wolfSSL version 4.8.0, we have enabled socat to be able to call into wolfSSL through the OpenSSL compatibility layer. You can access the GitHub page here: https://github.com/wolfSSL/osp/tree/master/socat

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

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 is now safe against the “Harvest Now, Decrypt Later” post-quantum threat model with the addition of our new TLS 1.3 post-quantum groups. But where does that leave wolfSSH? It is still only using RSA and elliptic curve key exchange algorithms which are vulnerable to the threat model mentioned above.

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 Linux kernel module support has grown by leaps and bounds, with new support for public key (PK) cryptographic acceleration, FIPS 140-3, accelerated crypto in IRQ handlers, portability improvements, and overall feature completeness.

The module provides the entire libwolfssl API natively to other kernel modules, allowing fully kernel-resident TLS/DTLS endpoints with in-kernel handshaking.  Configuration and building is turnkey via the --enable-linuxkm option, and can optionally be configured for cryptographic self-test at load time (POST), including full FIPS 140-3 core hash integrity verification and self-test.

As with library builds, the kernel module can be configured in detail to meet application requirements, while staying within target capabilities and limitations.  In particular, developers can opt to link in only the wolfCrypt suite of low level cryptographic algorithms, or can include the full TLS protocol stack with TLS 1.3 support.

For PK operations, the kernel module leverages our new function-complete SP bignum implementation, featuring state of the art performance and side channel attack immunity.  AVX2 and AES-NI accelerations are available on x86, and are usable from both normal kernel threads and from interrupt handler contexts. When configured for AES-NI acceleration, the module delivers AES256-GCM encrypt/decrypt at better than 1 byte per cycle.

Kernel module builds of libwolfssl are supported in wolfSSL release 4.6 and newer, and are available in our mainline github repository, supporting the 3.x, 4.x, and 5.x Linux version lines on x86-64, with limited support for ARM and MIPS. Full FIPS 140-3 support on x86-64 will be available in the forthcoming wolfSSL Version 5.0 release.

Need more? Subscribe to our YouTube channel for access to wolfSSL webinars!
Love it? Star us on GitHub!

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

It came to our attention that OpenSSL just published two new vulnerabilities.

• CVE-2021-3711 – “SM2 decryption buffer overflow” (nakedsecurity)
• CVE-202103712 – “Read buffer overruns processing ASN.1 strings.” (nakedsecurity)

These were specific OpenSSL issues and do not affect wolfSSL. For a list of CVEs that apply to wolfSSL please watch the security page on our website here: https://www.wolfssl.com/docs/security-vulnerabilities/

We wanted to take this opportunity to remind our customers and users that wolfSSL is in no way related to OpenSSL. wolfSSL was written from the ground up and is a unique SSL/TLS implementation.

That being said, wolfSSL does support an OpenSSL compatibility layer allowing OpenSSL users to drop in wolfSSL but continue to use the most commonly found OpenSSL API’s after re-compiling their applications to link against wolfSSL.

One individual also pointed out the time delta between report and fix on the above CVEs and wolfSSL would like to remind our customers and users of how proud we are of our less than 48 hour delta between report and fix. For more on our response time and process regarding vulnerabilities check out https://www.wolfssl.com/everything-wanted-know-wolfssl-support-handles-vulnerability-reports-afraid-ask/

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

A quick followup to the post “wolfSSLs’ Proprietary ACVP client”.

wolfSSL Inc. is proud to announce a recent addition to the wolfCrypt FIPS cert 3389!

• CMSIS-RTOS2 v2.1.3 running on a Silicon Labs EFM32G (Giant Gecko) chipset with wolfCrypt v4.6.1

Testing and standup for the EFM32 Giant Gecko was done collaboratively between wolfSSL Inc. and one of wolfSSLs’ customers. wolfCrypt had not previously been ported to or run on an EFM32 device so this was an exciting opportunity to both test on an EFM32 for the first time and to take wolfCrypt, running on the EFM32, through FIPS certification!
If you have any questions about getting wolfCrypt or wolfSSL up and running on your EFM32 target, not only is it possible, it is possible with FIPS 140-2 (and soon FIPS 140-3) certification as well!

Other OE’s added since the original ACVP client post are:

• Linux 4.14 running on ARMv8 Cortex A53 with and without PAA (module version 4.5.4)
• Windows CE 6.0 running on ARM Cortex-A8 (module version 4.6.2)
• Linux 4.19 running on ARMv8 Cortex A53 with and without PAA (module version 4.5.4)

At the time of this posting wolfSSL has:

• 10 OE additions (1SUB) in coordination phase with the CMVP to be added to cert 3389
• 4 OE additions (1SUB) that have completed all testing and are ready to be submitted to the CMVP
• 5 OE additions (1SUB) actively in the testing process
• 1 OE addition (1SUB) in the queue to start

While the CMVP is no longer accepting 3SUB and 5SUB submissions for FIPS 140-2 (Cutoff date was 22 Sep 2021) wolfSSL Inc. continues to work on 1SUB OE additions. wolfSSL Inc. will continue to work on 1SUB OE additions to cert 3389 until 7 months before the expiration date of cert 3389.

wolfSSL Inc. was one of the first to submit for FIPS 140-3 and we expect to be one of the first to receive a 140-3 certificate. If you are looking for a commercial FIPS 140-3 solution, then look no further!

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

Recently, a lot of post-quantum activity has been happening here at WolfSSL.

First, we’ve simplified and unified our naming conventions for the variants of the post-quantum algorithms. We now refer to each variant by the algorithm submitter’s claimed NIST level. For example, what used to be referred to as  LIGHTSABER is now known as SABER_LEVEL1 in our command-line applications and APIs.

We are now working towards making cURL resistant to  “harvest now; decrypt later” attacks from a future quantum-enabled adversary.  This protection is important if you value confidentiality over the long term.  Do you know how long your data need to stay confidential?

This effort involves enabling the the use of the new post-quantum groups for TLS 1.3 in cURL when built with wolfSSL.  For more details, please have a look at the following pull request: https://github.com/curl/curl/pull/7728.  Once the GitHub pull request is merged, it will go into the next release of cURL.

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

Adding security to a connection comes at a cost. It takes a little time to perform the crypto operations and some memory gets used during the operations. Not all TLS implementations are equal … how much memory and how much time is lost depends on what TLS library is being used.

Recently OpenSSL came out with their 3.0.0 version and we did a quick collection of runtime memory used. Both to re-collect and make sure wolfSSL has not gotten any unexpected bloat and to check out what OpenSSL has done with their long awaited update. What we found surprised us. To run a simple, single TLS 1.2 connection OpenSSL 3.0.0 took up over 800 KiB of memory where wolfSSL 4.8.1 took up 37.4 KiB. This was collected using the very basic example TLS server from wolfssl-examples/tls/server-tls.c where the functions in it were changed to the OpenSSL versions (i.e. wolfSSL_new -> SSL_new), and changed to run a single connection instead of a loop. First linked to OpenSSL 3.0.0 then to wolfSSL 4.8.1. The memory used during the single connection was collected using Valgrind’s massif tool and then converted into a graph with massif-visualizer.

The memory usage difference between the two libraries is dramatic. A lot of the memory usage with OpenSSL 3.0.0 appears to be surrounding the startup/shutdown code but even when trimming that necessary portion of the runtime memory usage off, it takes over 100 KiB per connection versus wolfSSL’s 13.9 KiB per connection. This makes OpenSSL 3.0.0 difficult if not impossible to be used in some IoT devices and also requires more resources when scaled to large server use cases. Leading to more hardware required and more memory to handle the same number of connections (more $$$).

You may ask though, what about performance? wolfSSL has a SP version that has optimizations for the public key algorithms commonly used in TLS connections. To configure with the “small” version of these optimizations the build “./configure –enable-opensslextra –enable-sp-math-all=small –enable-sp=small” could be used. Recollecting memory usage with the same server-tls.c app linked to the sp small version of wolfSSL used 26.3 KiB. Even less memory than before because along with optimizations for speed some optimizations for memory are also turned on.

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

Recently, we announced our wolfSSL libOQS integration and we said we were planning to hybridize our KEMs with NIST-standardized ECDSA. The hybridization is completed. This is a brief summary of why this matters and what we did.

It might come as a shock, but the sad truth is that we do not actually know that these algorithms will resist attacks from quantum computers. But wait, it gets worse. We don’t even know that these algorithms are safe against a conventional computer!! For all we know, someone could break lattice-based cryptography tomorrow.  Please don’t panic.  Why? Because this is how cryptography has always worked.

We started using ECC because it looked promising and as more and more people studied it and tried to break it and failed, the more we trusted it. We never actually knew that ECC was safe, but no matter how hard we tried, we simply could not break it and so we trusted it. But now we know we will have quantum computers so we have to move to something else.

So what do we do? One solution is to not put our full faith into these new algorithms. For now, in the early days, we can hedge our bets by hybridizing post-quantum algorithms with cryptographic algorithms that we actually trust. ECC with NIST standardized curves seem like good candidates and we have to keep using them anyways since FIPS compliance is a priority.

This brings up a very important point. You can now experiment with post-quantum cryptography while staying FIPS compliant. This is a quote from the NIST PQ Crypto FAQ at https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs:

> Additionally, NIST plans to incorporate a cleaner, and therefore preferable, hybrid key establishment construction in a future revision of SP 800-56C:

> In any of the key derivation methods specified in SP 800 – 56C, the revision would permit a concatenation of Z and T, e.g.,  Z||T, to serve as the shared secret instead of Z. This would require the insertion of T into the coding for the scheme and the FIPS 140 validation code may need to be modified.

This means that as you are testing and experimenting in preparation for your migration to post-quantum cryptography you can do it in a more realistic situation; an environment that uses FIPS-certified software.

So how do we achieve hybridization? We followed the design described in https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-03.txt. In a nutshell:

– The client’s key share is the classical public key concatenated with the post-quantum public key.
– The server’s key share is the classical public key concatenated with the post-quantum ciphertext.
– The shared secret is the classical shared secret concatenated with the post-quantum shared secret.

The future on the cryptography landscape is scary and exciting. We at wolfSSL Inc want to help you navigate these dangers with cutting edge technologies so that calm is what you’ll be feeling with wolfSSL in your corner..

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 post has been cross posted from Daniel Stenberg’s blog – originally posted here.

Within 24 hours of the previous release, 7.79.0, we got a bug-report filed that identified a pretty serious regression in the HTTP/2 code that we deemed required a fairly quick fix instead of waiting a full release cycle for it.

So here’s 7.79.1 with several bug-fixes that we managed to queue up and merge in the seven days since the previous release. Enjoy

Release presentation

Numbers

the 203rd release
0 changes
7 days (total: 8,587)
10 bug-fixes (total: 7,280)
17 commits (total: 27,668)
0 new public libcurl function (total: 85)
0 new curl_easy_setopt() option (total: 290)
0 new curl command line option (total: 242)
11 contributors, 5 new (total: 2,489)
3 authors, 0 new (total: 948)
0 security fixes (total: 111)
0 USD paid in Bug Bounties (total: 16,900 USD)

Bug-fixes

This was a very short release cycle but there were two rather annoying bugs fixed and we also managed to get a few other corrections merged since they arrived perfectly timed…

HTTP/2: don’t change connection data

For one of the HTTP/2 fixes I was happy to land for 7.79.0 I overdid it a little and change a few lines too many. This caused my previous “fix” to also break common use cases and I had to follow up with this additional fix.

The reason this bug managed to sneak in, is that we don’t have test cases exercising this code path that depends on multiple concurrent HTTP/2 streams over a single connection.

fix the broken >3 digit HTTP response code detection

Probably the second worst bug and regression added in the previous release. When I made the HTTP/1 response code parser stricter and made it allow no more than three digits I messed up my sscanf() fu and forgot that %d also skips leading space. This made curl treat responses that had a fine response code that were followed by a leading digit in the “reason phrase” field get detected as badly formatted and rejected! Now we have test cases verifying this.

curl_multi_fdset: make FD_SET() not operate on sockets out of range

This function would wrongly skip the check for a too large file descriptor if libcurl was built to use poll(), which in this case was a totally unrelated and wrong check. Unfortunately, we don’t (yet) have test cases to catch FD_SETSIZE issues.

provide lib/.checksrc in the tarball

When you build curl with --enable-debug or otherwise run ‘make checksrc’, the code style is changed and due to this missing control file, it would erroneously report an error. The error happened because within a source file a specific checksrc-warning is disabled, but since lib/.checksrc was missing the warning was never enabled in the first place and this discrepancy was not allowed. We didn’t catch this before release because we don’t test-build release tarballs with debug enabled in the CI…

CURLSTS_FAIL from hsts read callback should fail transfer

libcurl didn’t properly handle this return code from the HSTS read callback. Instead of failing the transfer it would just continue! Now we have test cases verifying this.

handle unlimited HSTS expiry

When using HSTS and passing in an entry to libcurl that you specify should never expire, libcurl would pass that the maximum time_t value as an argument to the gmtime() function. The problem is then just that on 64 bit systems, the largest possible time_t value is so big that when converted into a struct tm, the number of years would still overflow the year struct field! This causes the function to return a NULL and libcurl would misbehave. Now we have test cases verifying this.

use sys_errlist instead of strerror on Windows

Another little fix to avoid strerror() on Windows as well where it also is documented as not thread-safe.

make the ssh tests work with openssh-8.7p1

The test suite fired up openssh for testing purposes in a way that no longer is accepted by this OpenSSH version.

Next

We will not change the schedule for next release due to this patch version. It means that the next feature window will instead be one week shorter than usual and that the next release remains set to get released on November 10, 2021.

Support

• wolfSSL offers Curl support is available, and part of that support revenue goes into finding and fixing these kinds of vulnerabilities.
•  Customers under curl support can get advice on whether or not the advisories apply to them.
•  24×7 support on curl is available, and can include pre-notification of upcoming vulnerability announcements.

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