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 are interested in knowing about our plans to protect wolfSSH using post-quantum key exchanges, please get in contact with us at email@example.com.
Join our live wolfEngine webinar, where we introduce one of our newest products wolfEngine, a separate standalone library which links against wolfSSL (libwolfssl) and OpenSSL. wolfEngine implements and exposes an OpenSSL engine implementation which wraps the wolfCrypt native API internally. Algorithm support matches that as listed on the wolfCrypt FIPS 140-2 certificate #3389.
Learn about about what wolfEngine is, why you should care, and why wolfEngine could be the solution to all of your problems. As always bring your questions for the Q&A following the presentation.
wolfEngine : wolfCrypt as an Engine for OpenSSL
Time: Oct 7, 2021 09:00 AM in Pacific Time
Register here: https://us02web.zoom.us/webinar/register/WN_1gPXMVUgReClAodxe7sTPg
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.
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/
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 need FIPS 140-2 or 140-3 please don’t hesitate to reach out to firstname.lastname@example.org anytime.
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.
For more information contact us at email@example.com!
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.
For questions about wolfSSL and our resource usage contact firstname.lastname@example.org.
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..
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
the 203rd release
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)
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.
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.
- 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.
Contact us at email@example.com to learn more.
There are many reasons why a user might want to switch from OpenSSL to wolfSSL. In order to facilitate this transition, wolfSSL has an accessible compatibility layer.
Why might one want to make this migration and turn on this compatibility in the first place? To start, wolfSSL has numerous benefits over its counterpart, OpenSSL. Some of these include hardware acceleration implementations, progressive adoptions of TLS 1.3 as well as a reduced footprint size. In addition to this, there is the potential to use wolfSSL FIPS. wolfSSL maintains current FIPS support and is used in numerous applications and provides FIPS Ready builds to help get projects ready for FIPS verification. All of this is supported by a team of trained wolfSSL engineers.
What is the wolfSSL OpenSSL compatibility layer?
The wolfSSL OpenSSL compatibility layer is a means to switch applications designed for OpenSSL to wolfSSL. In addition to this, it is constantly expanded with more than 500 commonly used OpenSSL functions. wolfSSL also provides Crypto API support to enable easier migration of projects.
To learn more about migrating from OpenSSL to wolfSSL, we would like to invite you to a webinar presented by wolfSSL.
wolfSSL Engineer, Jacob Barthelmeh, will talk about the top reasons why people migrate from OpenSSL to wolfSSL as well as how to get started. He will cover how to build with the compatibility layer as well as some examples of applications. Please come with any questions you may have!
When: Friday, Sep 24, 2021 10:00 AM Pacific Time (US and Canada)
Topic: Migrating from OpenSSL to wolfSSL
Register in advance for this webinar: https://us02web.zoom.us/webinar/register/WN_MtyxJ2t7RUOr7SjUsn9tuQ
After registering, you will receive a confirmation email containing information about joining the webinar.
See you there!