RECENT BLOG NEWS
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.
wolfSSL version 5.5.0 is available now! Say hello to QUIC support. With this release of wolfSSL we have added in QUIC support and can be used with QUIC implementations such as ngtcp2 (https://github.com/ngtcp2/ngtcp2); which means wolfSSL can now be used for the TLS portion of HTTP/3 connections in cURL. Along with QUIC support this release saw additions for: RSA-PSS certificate support, Dilithium post quantum algorithm use with TLS, and some additional porting to even more embedded devices to name a few things. In addition to the new features added, there were enhancements to some of the existing ones, such as the expansion of ABI support, along with some fixes like with DTLS 1.3 asynchronous builds.
As TrueNuff.tv demonstrated in their “Does it blend?” series, by using a blender you will find out what things are really made of. Inspired by this, wolfSSL sponsored a new QUIC related test suite for the ngtcp2 project. What does it do and how does it help you in using wolfSSL?
Ngtcp2 is the leading open source QUIC implementation. We added wolfSSL support to it, as covered in our blog. Next to wolfSSL, most other TLS/SSL libraries are also supported: the quictls fork of OpenSSL, BoringSSL, GnuTLS, picotls. Libressl is expected to join soon. (OpenSSL itself is missing and is not expected to play a role in QUIC for the foreseeable future. We covered that in the mentioned blog post.)
What you as a user of wolfSSL are most interested in is not only that you get state-of-the-art TLS, but that it communicates correctly and efficiently with all the other TLS libraries out there. Now and for all future releases coming.
QUIC’s use of TLS is very similar to TCP, but there are some differences. By testing TLS libraries against each other in the context of QUIC, we can verify not only interop for QUIC itself, but stress combinations of features and configurations that are used in “normal” TLS connections as well.
The ngtcp2 test suite has become part of ngtcp2 itself. It is added to its CI on github, so all future development and new releases – of wolfSSL and all other TLS implementations – are always verified.
You can run this yourself. On ngtcp2’s github are the instructions to checkout and build it yourself. The new test suite has its own README, explaining how to use it. The test suite is based on Python’s pytest and should run on all platforms that support it.
There are “examples” server and client executables in ngtcp2, one for each TLS library that you configured. Should you only configure `–with-wolfssl`, only the wolfSSL server and client are built. The test suite then verifies in various scenarios that they interoperate.
If you configure more TLS libraries in ngtcp2, say `–with-wolfssl –with-openssl`, then you get two servers and two clients. The tests then try all possible combinations: wolfssl-wolfssl, openssl-openssl, openssl-wolfssl and wolfssl-openssl. Meaning, you do not need all the TLS libraries to run the blender on your machine.
Should you develop your own QUIC application, the test suite is an excellent place to verify it. It runs executables against each other. It is fairly straightforward to modify it for your own purposes.
We are, for example, currently considering how to use it for testing curl, the swiss army knife for internet transfers, sponsored by wolfSSL. We added wolfSSL QUIC support in curl, using ngtcp2, and the test coverage there needs to be extended as well.
We think by donating this test suite to the ngtcp2 project, it’ll serve everyone best. We could have made it part of wolfSSL’s CI suites, but that would be a barrier for other TLS projects to pick it up. Also, should interop problems arise, let’s say between GnuTLS and BoringSSL, we do not really want to be involved in resolving it.
This aspect of OSS where things can be added and stay accessible where they make most sense is a real strength. We are happy to contribute.
Contact us at email@example.com with any questions.
wolfCLU 0.1.0 is available! wolfCLU is the wolfSSL’s Command Line Utility and is meant to be used for simple key generation, certificate operations, encryption, and more. It is also being developed to be an alternative for the commonly used OpenSSL command line utility. In addition to supporting platforms like Windows and FreeRTOS, there were vast feature enhancements over the last release. Support for several new flags were added in.
- s_client : -CAfile and -verify_return_error
- verify : -partial_chain
- enc : -pass
- crl : -text
- req : -passout
- x509 : -modulus
This release also included several fixes. A running list of changes can be found in the bundled ChangeLog.md. Visit our download page or https://github.com/wolfssl/wolfclu for downloading the bundle. Email us at firstname.lastname@example.org with any questions.
The fall release of wolfMQTT, v1.14.1, is now available! This is a point release that updates support for the vcpkg integration:
- Fix cmake builds #307
- Fix for Vcpkg on Windows not getting wolfssl/options.h included #305
The Microsoft vcpkg project allows applications to easily build, use, and update C libraries.
You can download and install wolfMQTT using vcpkg:
git clone https://github.com/Microsoft/vcpkg.git cd vcpkg ./bootstrap-vcpkg.sh
OR for Windows
bootstrap-vcpkg.bat ./vcpkg integrate install ./vcpkg install wolfmqtt
The wolfMQTT port in vcpkg is kept up to date by wolfSSL.
We also have vcpkg ports for wolftpm, wolfssl and curl.
Check out the changelog from the download for a full list of features and fixes, or contact us at email@example.com with any questions:
While you’re there, show us some love and give the wolfMQTT project a Star!
You can download the latest release here: https://www.wolfssl.com/download/
Or clone directly from our GitHub repository: https://github.com/wolfSSL/wolfMQTT
The cURL Project and wolfSSL is happy to announce the annual cURL Developers Conference, cURL Up has been rescheduled for Thursday September 15, 2022! cURL Up will be held virtually this September giving allowing the world – wide cURL community to join.
cURL Up is the annual curl developers conference where we gather and talk Internet protocols, curl’s past, current situation and how to design its future.
This is an intimate and very friendly meetup where you will have the opportunity to talk to Daniel Stenberg, founder and maintainer of cURL, as well as other speakers and sponsors about cURL and related technologies.
The first 50 registrants get some awesome swag!
When: Sep 15, 2022 06:00 AM Pacific Time (US and Canada)
Register in advance for this webinar:
After registering, you will receive a confirmation email containing information about joining the webinar.
If you have questions or comments contact us at firstname.lastname@example.org
wolfSSL’s controlled and maintained Application Binary Interface (ABI) coverage has been extended by 50 APIs to now have a total of 113. This includes parts of wolfCrypt including the Certificate APIs. This ensures that these APIs do not change over time so that any application using them will not be negatively impacted by upgrading to future releases of wolfSSL.
One of our goals at wolfSSL is to make sure that adopting our leading edge security solutions is as easy as possible. This includes helping our customers transition from an older version of wolfSSL to the latest version, with enhanced security, as easy as possible. The ABI coverage is one part in helping our customers with a smooth and easy transition.
Do you have questions about our ABI coverage?
Would you like to request enhancements or additional coverage?
Contact us at email@example.com
Here at wolfSSL, we think it is fair to say that we’ve been as busy as beavers with our post-quantum efforts! Here is a round up of updates on our post-quantum efforts over the last few weeks of summer.
Webinar with Guest Speaker Professor Douglas Stebila
Want to get a better understanding of what is going on when you do a post-quantum key exchange using Kyber KEM and hear some of the latest news on post-quantum cryptography? Tune in to our recent webinar with professor Douglas Stebila where he eases in on the inner workings of the Kyber KEM algorithm and how it works. You can find the video here: https://youtu.be/nOcRk5jVGYU .
Dilithium in wolfSSL
We have added support for all parameter sets of Dilithium in the NIST Round 3 submission. This includes levels 1, 3 and 5 of the SHAKE and AES variants. Of course we have full interoperability with the OQS’s OpenSSL fork for X.509 certificates and TLS 1.3.
SPHINCS+ in wolfCrypt
We have added support for a limited number of parameter sets of the NIST Round 3 submission of SPHINCS+. This includes levels 1, 3 and 5 of fast and small optimizations of the SHAKE simple variant . Notably we did not include the robust variant. We also did not include the SHA256 variant nor the Haraka variant. Since signatures are fairly large, we did not integrate SPHINCS+ into our TLS 1.3 implementation. SPHINCS+ is more appropriate for other protocols. For example, code signing. Of course we have full interoperability with the OQS’s OpenSSL fork for X.509 certificates if you enable the variants we support in OQS’s OpenSSL fork. We have instructions for that here: https://github.com/wolfSSL/osp/blob/master/oqs/README.md
With the new integrations of Dilithium and SPHINCS+ along with our previous integrations of Kyber and Falcon, we now have coverage of all the algorithms that are moving on from NIST’s PQC Competition to standardization!
P256-kyber hybrid in wolfSSH
Originally we had integrated Saber KEM into wolfSSH, but it had been announced that it will no longer be considered for standardization. As such, instead of removing it from wolfSSH, we decided to replace it with ECDHE over the P-256 curve hybridized with Kyber Level1. Of course this has full interoperability with OQS’s fork of OpenSSH. Please give it a try by fetching from our wolfSSH github repo!
Blog PQ and DTLS 1.3
Credit goes to Callum McLoughlin of the University of Cantebury, one of our newest contributor to wolfSSL, for enabling post-quantum key exchange KEMs in DTLS 1.3. He’s done an excellent job making changes and testing them out all while keeping the wolfSSL team informed of his progress. Thanks so much Callum!
If you want to experiment with post-quantum algorithms in DTLS 1.3 you can find detailed instructions in the pull request at https://github.com/wolfSSL/wolfssl/pull/5518 .
If all of this still isn’t enough for you, then show up at our booth at ICMC 2022. Our engineers and business staff would love to talk about post-quantum cryptography with you!
For questions about the release contact firstname.lastname@example.org
wolfSSL release 5.5.0 contained 4 vulnerability fixes. Most are considered low severity and affect a very small subset of users. 3 of the listed issues were found by external researchers (thanks to their efforts! you can see them mentioned on each of the reports) The last one listed with a potential DTLS DoS attack was found thanks to our internal testing.
|CVE-2022-38153||Low||In wolfSSL version 5.3.0 if compiled with –enable-session-ticket and the client has non-empty session cache, with TLS 1.2 there is the possibility of a man in the middle passing a large session ticket to the client and causing a crash due to an invalid free. There is also the potential for a malicious TLS 1.3 server to crash a client in a similar manner except in TLS 1.3 it is not susceptible to a man in the middle attack. Users on the client side with –enable-session-ticket compiled in and using wolfSSL version 5.3.0 should update their version of wolfSSL.
Thanks to Max at Trail of Bits for the report and “LORIA, INRIA, France” for research on tlspuffin.
|CVE-2022-38152||Low||If using wolfSSL_clear to reset a WOLFSSL object (vs the normal wolfSSL_free/wolfSSL_new) it can result in runtime issues. This exists with builds using the wolfSSL compatibility layer (–enable-opnesslextra) and only when the application is making use of wolfSSL_clear instead of SSL_free/SSL_new. In the case of a TLS 1.3 resumption, after continuing to use the WOLFSSH object after having called wolfSSL_clear, an application could crash. It is suggested that users calling wolfSSL_clear update the version of wolfSSL used.
Thanks to Max at Trail of Bits for the report and “LORIA, INRIA, France” for research on tlspuffin.
|N/A||Low||Fault injection attack on RAM via Rowhammer leads to ECDSA key disclosure. Users doing operations with private ECC keys such as server side TLS connections and creating ECC signatures, who also have hardware that could be targeted with a sophisticated Rowhammer attack should update the version of wolfSSL and compile using the macro WOLFSSL_CHECK_SIG_FAULTS.
Thanks to Yarkin Doroz, Berk Sunar, Koksal Must, Caner Tol, and Kristi Rahman all affiliated with the Vernam Applied Cryptography and Cybersecurity Lab at Worcester Polytechnic Institute for the report.
|N/A||Medium||Potential DoS attack on DTLS 1.2. In the case of receiving a malicious plaintext handshake message at epoch 0 the connection will enter an error state reporting a duplicate message. This affects both server and client side. Users that have DTLS enabled and in use should update their version of wolfSSL to mitigate the potential for a DoS attack.|
If not free’ing FP_ECC caches per thread by calling wc_ecc_fp_free there is a possible memory leak during TLS 1.3 handshakes which use ECC. Users are urged to confirm they are free’ing FP_ECC caches per thread if enabled to avoid this issue.
For additional vulnerability information visit the vulnerability page at https://www.wolfssl.com/docs/security-vulnerabilities/.
A full list of what was changed can be found in the wolfSSL ChangeLog (https://www.wolfssl.com/docs/wolfssl-changelog/).
If you have a vulnerability to report or would like more information, contact us at email@example.com, the wolfSSL development team takes vulnerabilities seriously.
wolfSSL’s GoLang wrapper, go-wolfssl, now includes a first round of wolfCrypt APIs. The wolfCrypt cryptography engine is a lightweight crypto library written in ANSI C and known for its small size, speed, and feature set, as well as its royalty-free pricing and excellent cross-platform support. Now with go-wolfssl, GO users can take advantage of this crypto engine and the many algorithms/ciphers it supports. The recently added features include ECC sign/verify, SHA hashing, and AES encryption.
Although it’s still in its early stages, factors like optimization, FIPS validation, and excellent customer support from our expert engineers make go-wolfssl the ideal TLS/crypto solution for GO projects in the long run.
Are you interested in a more complete Golang wrapper?
Contact us at firstname.lastname@example.org with any questions, comments, or suggestions!
Here at wolfSSL we love TLS 1.3, but we also know there are other protocols out there such as: DTLS, QUIC, SSH, MQTT and Noise. In this post we will compare and contrast TLS 1.3 against Noise and provide some notes about FIPS-140 and post-quantum cryptography.
Noise itself is NOT a protocol per se; it is a protocol framework (here lies the biggest difference between TLS 1.3 and Noise). When using TLS 1.3 the connection will be authenticated, confidential, and have integrity. It is quite simple and efficient to get these properties. All of wolfSSL’s example server and client applications that do TLS 1.3 are just a few hundred lines of code and the simplest can easily be under 100 lines (found here:https://github.com/wolfSSL/wolfssl-examples/tree/master/tls). Contrast that with the requirement that you need to design your own Noise-based protocol depending on the security properties that you desire, and suddenly Noise looks a bit more challenging than TLS 1.3. Expertise is required! See section 7.5 of https://noiseprotocol.org/noise.html to see the fundamental patterns that can be used.
The next biggest difference is authentication. TLS usually requires the server to have an X.509 certificate so the client can verify the identity of the server. The server’s identity is bound to the public key via the certificate and is verified by proving possession of the private key to the client. The Noise Framework does not support identity verification; it leaves that to the application. However, it does allow for using static encryption keys which then ensures that each side is talking to the same party they were talking to in the past. And again, you must design or use the correct pattern to achieve this goal and then design identity verification into your application.
TLS 1.3 standardizes the cryptographic algorithms and NIST gives guidance on which algorithms to use in it. As a result, it is easy to stay in compliance with FIPS-140. For example, if you simply use wolfSSL’s defaults in our FIPS-certified product, you will be fine. On the other hand, for Noise, NIST has given no guidance so you are on your own when you design your protocol or pick your patterns.
Can you do post-quantum cryptography in TLS 1.3 today? Yes! There are private use code points for the Supported Groups Extension and Signature Algorithm Extension. However, once post-quantum algorithms are standardized, standard codepoint and OIDs should quickly follow. The mechanics and cryptographic artifacts of post-quantum signature schemes and KEMs (key encapsulation mechanism) fit quite nicely into the TLS 1.3 handshake and X.509 certificate PKI. For more details, you can read our documentation about post-quantum TLS 1.3 in wolfSSL at https://www.wolfssl.com/documentation/manuals/wolfssl/appendix07.html. What about the Noise Framework? The short answer is no. The protocol framework relies on the “non-interactiveness” of the Diffie-Hellman key exchange protocol and KEMs are interactive! There are no known post-quantum non-interactive key exchange algorithms as of the time of this writing. However, research into different possibilities is ongoing and the Noise Protocol framework could eventually evolve into supporting post-quantum algorithms. For example, please see https://eprint.iacr.org/2022/539.pdf.
Our conclusion is that if TLS 1.3 can get you what you need, then keep it simple and use TLS 1.3.
For any questions, or to get help using wolfSSL in your product or projects, contact us at email@example.com.
wolfCrypt JNI/JCE provide Java-based applications with an easy way to use the native wolfCrypt cryptography library. The thin JNI wrapper can be used for direct JNI calls into native wolfCrypt, or the JCE provider (wolfJCE) can be registered as a Java Security provider for seamless integration underneath the Java Security API. wolfCrypt JNI/JCE can work with wolfCrypt FIPS 140-2 (and upcoming 140-3) as well!
Release 1.4.0 of wolfCrypt JNI has bug fixes and new features including:
- Add example directory with one simple ProviderTest example (PR 32)
- Fix double free of ChaCha pointer (PR 34)
- Add test cases for ChaCha.java (PR 34)
- Skip WolfCryptMacTest for HMAC-MD5 when using wolfCrypt FIPS 140-3 (PR 35)
- Use new hash struct names (wc_Md5/wc_Sha/etc) in native code (PR 35)
- Fix potential build error with non-ASCII apostrophes in Fips.java (PR 36)
Version 1.4.0 can be downloaded from the wolfSSL download page, and an updated version of the wolfCrypt JNI/JCE User Manual can be found here. For any questions, or to get help using wolfSSL in your product or projects, contact us at firstname.lastname@example.org.
- September 2022 (6)
- August 2022 (12)
- July 2022 (11)
- June 2022 (15)
- May 2022 (11)
- April 2022 (14)
- March 2022 (12)
- February 2022 (21)
- January 2022 (13)
- December 2021 (13)
- November 2021 (29)
- October 2021 (15)
- September 2021 (15)
- August 2021 (13)
- July 2021 (21)
- June 2021 (19)
- May 2021 (12)
- April 2021 (12)
- March 2021 (27)
- February 2021 (29)
- January 2021 (22)
- December 2020 (21)
- November 2020 (14)
- October 2020 (7)
- September 2020 (22)
- August 2020 (11)
- July 2020 (8)
- June 2020 (14)
- May 2020 (15)
- April 2020 (14)
- March 2020 (4)
- February 2020 (24)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (31)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (10)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (10)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (5)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (8)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)