RECENT BLOG NEWS

This post has been cross posted from Daniel Stenberg’s blog – originally posted here.

Welcome to the 200th curl release. We call it 200 OK. It coincides with us counting more than 900 commit authors and surpassing 2,400 credited contributors in the project. This is also the first release ever in which we thank more than 80 persons in the RELEASE-NOTES for having helped out making it and we’ve set two new record in the bug-bounty program: the largest single payout ever for a single bug (2,000 USD) and the largest total payout during a single release cycle: 3,800 USD.

This release cycle was 42 days only, two weeks shorter than normal due to the previous 7.76.1 patch release.

Numbers

• the 200th release
• 5 changes
• 42 days (total: 8,468)
• 133 bug-fixes (total: 6,966)
• 192 commits (total: 27,202)
• 0 new public libcurl function (total: 85)
• 2 new curl_easy_setopt() option (total: 290)
• 2 new curl command line option (total: 242)
• 82 contributors, 44 new (total: 2,410)
• 47 authors, 23 new (total: 901)
• 3 security fixes (total: 103)
• 3,800 USD paid in Bug Bounties (total: 9,000 USD)

Security

We set two new records in the curl bug-bounty program this time as mentioned above. These are the issues that made them happen.

• CVE-2021-22901: TLS session caching disaster

This is a Use-After-Free in the OpenSSL backend code that in the absolutely worst case can lead to an RCE, a Remote Code Execution. The flaw is reasonably recently added and it’s very hard to exploit but you should upgrade or patch immediately.

The issue occurs when TLS session related info is sent from the TLS server when the transfer that previously used it is already done and gone.

The reporter was awarded 2,000 USD for this finding.

• CVE-2021-22898: TELNET stack contents disclosure

When libcurl accepts custom TELNET options to send to the server, it the input parser was flawed which could be exploited to have libcurl instead send contents from the stack.

The reporter was awarded 1,000 USD for this finding.

• CVE-2021-22897: schannel cipher selection surprise

In the Schannel backend code, the selected cipher for a transfer done with was stored in a static variable. This caused one transfer’s choice to weaken the choice for a single set transfer could unknowingly affect other connections to a lower security grade than intended.

The reporter was awarded 800 USD for this finding.

Changes

In this release we introduce 5 new changes that might be interesting to take a look at!

• Make TLS flavor explicit

As explained separately, the curl configure script no longer defaults to selecting a particular TLS library. When you build curl with configure now, you need to select which library to use. No special treatment for any of them!

• No more SSL

curl now has no more traces of support for SSLv2 or SSLv3. Those ancient and insecure SSL versions were already disabled by default by TLS libraries everywhere, but now it’s also impossible to activate them even in special build. Stripped out from both the curl tool and the library (thus counted as two changes).

• HSTS in the build

We brought HSTS support a while ago, but now we finally remove the experimental label and ship it enabled in the build by default for everyone to use it more easily.

• In-memory cert API

We introduce API options for libcurl that allow users to specify certificates in-memory instead of using files in the file system. See CURLOPT_CAINFO_BLOB.

Favorite bug-fixes

Again we manage to perform a large amount of fixes in this release, so I’m highlighting a few of the ones I find most interesting!

• Version output

The first line of curl -V output got updated: libcurl now includes OpenLDAP and its version of that was used in the build, and then the curl tool can add libmetalink and its version of that was used in the build!

• curl_mprintf: add description

We’ve provided the *printf() clone functions in the API since forever, but we’ve tried to discourage users from using them. Still, now we have a first shot at a man page that clearly describes how they work.

This is important as they’re not quite POSIX compliant and users who against our advice decide to rely on them need to be able to know how they work!

• CURLOPT_IPRESOLVE: preventing wrong IP version from being used

This option was made a little stricter than before. Previously, it would be lax about existing connections and prefer reuse instead of resolving again, but starting now this option makes sure to only use a connection with the request IP version.

This allows applications to explicitly create two separate connections to the same host using different IP versions when desired, which previously libcurl wouldn’t easily let you do.

• Ignore SIGPIPE in curl_easy_send

libcurl makes its best at ignoring SIGPIPE everywhere and here we identified a spot where we had missed it… We also made sure to enable the ignoring logic when built to use wolfSSL.

• Several HTTP/2-fixes

There are no less than 6 separate fixes mentioned in the HTTP/2 module in this release. Some potential memory leaks but also some more behavior improving things. Possibly the most important one was the move of the transfer-related error code from the connection struct to the transfers struct since it was vulnerable to a race condition that could make it wrong. Another related fix is that libcurl no longer forcibly disconnects a connection over which a transfer gets HTTP_1_1_REQUIRED returned.

• Partial CONNECT requests

When the CONNECT HTTP request sent to a proxy wasn’t all sent in a single send() call, curl would fail. It is baffling that this bug hasn’t been found or reported earlier but was detected this time when the reporter issued a CONNECT request that was larger than 16 kilobytes…

• TLS: add USE_HTTP2 define

There was several remaining bad assumptions that HTTP/2 support in curl relies purely on nghttp2. This is no longer true as HTTP/2 support can also be provide by hyper.

• normalize numerical IPv4 hosts

The URL parser now knows about the special IPv4 numerical formats and parses and normalizes URLs with numerical IPv4 addresses.

• Timeout, timed out libssh2 disconnects too

When libcurl (built with libssh2 support) stopped an SFTP transfer because a timeout was triggered, the following SFTP disconnect procedure was subsequently also stopped because of the same timeout and therefore wasn’t allowed to properly clean up everything, leading to a memory-leak!

IRC network switch

We moved the #curl IRC channel to the new network libera.chat. Come join us there!

Next release

On Jul 21, 2021 we plan to ship the next release. The version number for that is not yet decided but we have changes in the pipeline, making a minor version number bump very likely.

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.

Contact us at facts@wolfssl.com to learn more.

wolfSSL has a command-line utility, it’s called wolfCLU. As promised, here’s a sneak peek of notable additions to wolfCLU that are coming soon:

1. PKEY and certificate public key output
2. Certificate request creation
3. Updates to human readable text output of certificates

What do you want to see from wolfCLU? Download on GitHub today and write to facts@wolfSSL.com with your input!

Download wolfCLU: https://github.com/wolfSSL/wolfssl-examples/tree/master/wolfCLU
Love it? Star us on GitHub!

In case you didn’t know, wolfSSL has a portable command line utility. You can download wolfCLU on Github today for use with the wolfSSL embedded SSL/TLS library! wolfCLU (Command Line Utility) is backed by the best-tested crypto using wolfCrypt and it can make use of FIPS builds with wolfSSL!

wolfCLU currently has the following features:
– Support for ED25519 sign and verify
– Autoconf for portability
– Encrypt a file and store it locally on your computer
– Decrypt that file after it has been encrypted, or send it via email to your friend, if he/she knows the password and algorithm used for encryption, they can then decrypt it on their computer
– Hash a single file (IE a zip archive) for verification
– Benchmark the currently configured Algorithms
– X509 parsing and print out

Download wolfCLU: https://github.com/wolfSSL/wolfssl-examples/tree/master/wolfCLU
Love it? Star us on GitHub!

We’re back! wolfSSL will be hosting a webinar on common libcurl mistakes next Thursday, June 17th, 2021. Hear from cURL author and maintainer Daniel Stenberg on the most common mistakes developers make when using libcurl, how to troubleshoot, and best practices for making your libcurl applications seamless and secure.

Common libcurl Mistakes presented by Daniel Stenberg
Thursday, June 17th, 2021 at 9AM Pacific time (GMT-8)
Register below for the upcoming live webinar from wolfSSL:
https://us02web.zoom.us/webinar/register/WN_lwHCDuy5TxiG5RtYs8uoDQ 

Bring questions about our commercial curl support, tiny curl, curl with wolfCrypt FIPS, or the latest integration with MQTT. We look forward to having you join us! 

Additional resources:
– wolfSSL support for curl: https://www.wolfssl.com/products/curl/
– Daniel’s blog: https://daniel.haxx.se/blog/

Follow Daniel on Twitter @bagder
Follow wolfSSL on Twitter @wolfSSL

wolfTPM is the only TPM 2.0 library designed for baremetal and embedded systems. It also has native Windows and Linux support, alongside a TPM simulator for rapid development and testing.

When it comes to choosing a TPM 2.0 dedicated chip for your project, there are multiple options: Nuvoton NPCT75x, STMicroelectronics ST33, Infineon SLB9670, Microchip ATTPM20P, etc.

Here are our highlights when using ST33 chip with wolfTPM:

• Only wolfTPM supports GPIO control for ST33
  • Depending on the chip variant, a ST33 could offer up to four(4) extra GPIO 
  • The access to these GPIO is protected by the TPM 2.0 authorization
  • Making the GPIO control offered by wolfTPM a great tool for signaling across subsystems for critical, important or security events
  • wolfTPM also provides an open-source example code ready for use

• ST33 has the most Non-volatile memory storage on the market, right now
  • Typically, TPM 2.0 NVRAM storage is limited, this makes ST33  stand out. Multiple certificates and keys can be stored in the ST33 non-volatile memory
  • wolfTPM offers open-source examples on how to securely store secrets and keys in the TPM’s NVRAM

• Using ST33 for Automotive, Industrial, Medical and Aerospace devices with wolfTPM is easy
  • Critical-safety systems often use state machines and RTOS
  • Baremetal and RTOS do not provide driver for TPM 2.0
  • Thanks to wolfTPM’s design, using ST33 without a driver is possible
  • wolfTPM has its own internal TIS layer and direct support for I2C and SPI

• Using ST33 for IoT devices with wolfTPM is highly recommended, because our TPM 2.0 stack is lightweight. In comparison with other libraries, wolfTPM produces 20 times less code and 100 times less memory.
  
• Only ST33 supports AES symmetric operations for encryption and decryption by default, using TPM2_EncryptDecrypt2. Other TPM 2.0 modules support by default only AES CFB for parameter encryption.

Contact us at facts@wolfssl.com if you want more information about wolfTPM or if you have any questions about using ST33 TPM 2.0 in embedded systems.

We’re actually going somewhere! Come see wolfSSL at MWC ’21 in Barcelona this month. This year’s event is hybridized, so you can join us online or in-person.

MWC ‘21: June 28th – July 1st, 2021 at Fira Barcelona Gran Via

Get a virtual pass: https://www.mwcbarcelona.com/attend/registration#tab-virtual-passes 

Get a physical pass: https://www.mwcbarcelona.com/attend/registration#tab-physical-passes 

Exhibition hours: 9am-7pm (M-W), 9am-4pm (Th)

wolfSSL will be at booth 1L12, with Business Directors Wolfram Kusterer and Martin Engstrom on the ground to answer all your embedded security questions. Plus, our full sales team will be on standby in the virtual booth to talk to you! Email facts@wolfSSL.com if you’d like to book a meeting ahead of the event. 

If you’re new to wolfSSL, here’s how we can help you win big in mobile industry and beyond:

– wolfSSL is up to 20x smaller than OpenSSL 

– First commercial implementation of TLS 1.3, with TLS 1.3 Sniffer

– First in FIPS 140-3 

– Best tested, most secure, fastest crypto on the market with incomparable certifications and highly customizable modularity 

– Access to 24×7 support from a real team of Engineers 

– Support for the newest standards (including TLS 1.2, TLS 1.3, DTLS 1.2, and DTLS 1.3 forthcoming) 

– Multi-platform, dual-licensed, royalty free, with an OpenSSL compatibility API to ease porting into existing applications which have previously used the OpenSSL package 

– Full product suite including MQTT with support up to v5.0, Secure Boot, wolfSentry IDPS, SSHv2 server, TPM 2.0 portable project, Java wrappers and JSSE support, plus commercial curl support at the enterprise level. 

To learn more, come meet us at MWC ’21 or email facts@wolfSSL.com.  

Love it? Star wolfSSL on GitHub.

Discover MWC ‘21 here.

Follow @wolfSSL on Twitter for daily updates!

wolfSSL is up and running and tested on Apple’s new M1 chip, and with the right options it is blazing fast! We have decided to benchmark our wolfCrypt/wolfSSL libraries on the Apple M1, to show you just how well the the M1 will perform in our standard cryptographic benchmarks.

See below for more details!

If you have questions on these benchmarks, or if you would like some support to help replicate them on your system, let us know at facts@wolfSSL.com or give us a call!

The i.MX RT1060 is a powerful crossover MCU implementation of the Arm Cortex-M7 core, designed and produced by NXP. This MCU contains a TRNG and a data co-processor (DCP). The latter is capable of performing AES encryption and decryption, as well as calculating SHA and SHA256 digest.

Starting from version 4.7.0, wolfSSL provides a port driver that can redirect all the AES and SHA/SHA256 operations to the DCP, which has a number of advantages over the software implementation counterparts, reducing the footprint of the compiled library, improving performance and using less power.

The DCP driver can be enabled via the compile-time flag WOLFSSL_IMXRT_DCP, which delegates all the AES and SHA/SHA256 operations to the hardware co-processor. When this option is enabled, all TLS connections using these algorithms will rely on the hardware to perform the operations.

wolfSSL can also use the TRNG present in this core as an entropy source to seed the DRBG. Support for TRNG on this board can be enabled by adding the compile-time flag FREESCALE_KSDK_2_0_TRNG.

WolfSSL is not the only component in the product family that directly benefits from the presence of these secure elements on this target platform. SSH servers and clients based on wolfSSH will automatically use the accelerators for both SHA and AES when available and compiled in. The port for i.MX-RT1060 of wolfBoot, our secure bootloader, uses the SHA256 hardware acceleration to speed up the verification of the integrity of the firmware image. A full port of wolfBoot for i.MX-RT1060 is available, and its hardware abstraction layer is distributed with wolfBoot since version 1.7.1.

i.MX-RT1060 is a popular choice as edge computing platform, often deployed in combination with a real-time operating system and TCP/IP connectivity. WolfSSL, wolfSSH, wolfBoot and wolfMQTT can be easily added to these scenarios to enable secure communication, secure remote shell and filesystem services, as well as secure boot and remote firmware updates. The extra hardware security provided by DCP and TRNG makes the i.MX-RT1060 a reliable platform to build professional grade security with the latest standards.

Ask us more information about solutions based on i.MX RT1060 and other embedded systems, contact us today at facts@wolfssl.com.

As some may be aware, wolfSSL added support for strongSwan in April of 2019. The upstream commit can be reviewed here: https://github.com/strongswan/strongswan/pull/133

Users can test the latest development master of wolfSSL with the latest version of strongSwan using the following setup:

wolfSSL Build and Installation Steps

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

$ cd wolfssl
$ ./autogen.sh

$ ./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA"

$ make
$ make check
$ sudo make install

strongSwan Build and Installation Steps

# if the following packages are not already installed:
$ sudo apt-get install flex bison byacc libsoup2.4-dev gperf

$ git clone https://github.com/strongswan/strongswan.git
$ cd strongswan
$ ./autogen.sh

# if packages are missing autogen.sh must be re-run

$ ./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem
$ make
$ make check
$ sudo make install

wolfSSL has had interest in enabling FIPS 140-2/140-3 support with strongSwan so our engineers verified everything is working with the wolfCrypt FIPS 140-2 validated Module!

The steps wolfSSL used for testing are as follows:

Testing was done using the wolfSSL commercial FIPS release v4.7.0 which internally uses the wolfCrypt v4.0.0 FIPS 140-2 validated Crypto Module. It was located in the /home/user-name/Downloads directory on the target test system, Linux 4.15 Ubuntu 18.04 LTS running on Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz.

1. wolfSSL was configured and installed with these settings:

./configure --enable-opensslall --enable-keygen --enable-rsapss --enable-des3 --enable-dtls --enable-certgen --enable-certreq --enable-certext --enable-sessioncerts --enable-crl --enable-ocsp CFLAGS="-DWOLFSSL_DES_ECB -DWOLFSSL_LOG_PRINTF -DWOLFSSL_PUBLIC_MP -DHAVE_EX_DATA -DFP_MAX_BITS=8192" --enable-ed25519 --enable-curve25519 --enable-fips=v2 --enable-intelasm --prefix=$(pwd)/../fips-install-dir
 make
 make install

2. A custom install location was used which equated to /home/user-name/Downloads/fips-install-dir and the configuration for strongSwan accounted for this.
3. strongSwan was cloned to /home/user-name/Downloads with “git clone https://github.com/strongswan/strongswan.git”
4. StongSwan was configured and installed with these settings:

./configure --disable-defaults --enable-pki --enable-wolfssl --enable-pem --prefix=$(pwd)/../strongswan-install-dir wolfssl_CFLAGS="-I$(pwd)/../fips-install-dir/include" wolfssl_LIBS="-L$(pwd)/../fips-install-dir/lib -lwolfssl"
 make
 make install
 make check

5. In the make check stage of the test, it was observed that 1 test was failing.

 Passed 34 of 35 'libstrongswan' suites
 FAIL: libstrongswan_tests
 ==================
 1 of 1 test failed
 ==================

6. Reviewing the logs it was apparent one of the RSA tests was failing.
7. Upon further debugging it turned out the failure was a test in strongSwan that was attempting to create an RSA key size of 1536-bits.

Running case 'generate':
 DEBUG: key_sizes[_i] set to 1024
 + PASS
 DEBUG: key_sizes[_i] set to 1536
 - FAIL
 DEBUG: key_sizes[_i] set to 2048
 + PASS
 DEBUG: key_sizes[_i] set to 3072
 + PASS
 DEBUG: key_sizes[_i] set to 4096
 + PASS

wolfSSL has a function RsaSizeCheck() which in FIPS mode will specifically reject any non FIPS RSA key sizes so this failure was not only expected, but it is a good thing for those wanting to use strongSwan in FIPS mode and ensure only FIPS-validated RSA key sizes will be supported!

wolfSSL is pleased that with the latest release of wolfSSL v4.7.0 and the wolfCrypt FIPS 140-2 module validated on FIPS certificate 3389, strongSwan support is working splendidly and wolfSSL engineers will be making efforts to ensure continued support into the future!

If you have any questions about wolfSSL, wolfCrypt FIPS, or strongSwan and wolfSSL together please contact our support staff anytime at support@wolfssl.com or via our Zendesk portal by registering and opening a support incident at wolfssl.zendesk.com.