RECENT BLOG NEWS

author: Daniel Stenberg

Whatever we do and whatever we try, no matter how hard we try to test, debug, review and do CI builds it does not change the eternal truth:

Nothing gets tested properly until released.

We worked hard on fixing bugs in the weeks before we shipped curl 7.65.0. We really did. Yet, several annoying glitches managed to creep in, remain unnoticed and cause problems to users when they first eagerly tried out the new release. Those were glitches that none in the development team had experienced or discovered but only took a few hours for users to detect and report.

The initial bad sign was that it didn’t even take a full hour from the release announcement until the first bug on 7.65.0 was reported. And it didn’t stop with that issue. We obviously had a whole handful of small bugs that caused friction to users who just wanted to get the latest curl to play with. The bugs were significant and notable enough that I quickly decided we should patch them up and release an update that has them fixed: 7.65.1. So here it is!

This patch release even got delayed. Just the day before the release we started seeing weird crashes in one of the CI builds on macOS and they still remained on the morning of the release. That made me take the unusual call to postpone the release until we better understood what was going on. That’s the reason why this comes 14 days after 7.65.0 instead of a mere 7 days.

Numbers

the 182nd release
0 changes
14 days (total: 7,747)
35 bug fixes (total: 5,183)
61 commits (total: 24,387)
0 new public libcurl function (total: 80)
0 new curl_easy_setopt() option (total: 267)
0 new curl command line option (total: 221)
27 contributors, 12 new (total: 1,965)
16 authors, 6 new (total: 687)
0 security fixes (total: 89)
0 USD paid in Bug Bounties

Bug-fixes

Let me highlight some of the fixes that went this during this very brief release cycle.

build correctly with OpenSSL without MD4

This was the initial bug report, reported within an hour from the release announcement of 7.65.0. If you built and installed OpenSSL with MD4 support disabled, building curl with that library failed. This was a regression since curl already supported this and due to us not having this build combination in our CI builds we missed it… Now it should work again!

CURLOPT_LOW_SPEED_* repaired

In my work that introduces more ways to disable specific features in curl so that tiny-curl would be as small as possible, I accidentally broke this feature (two libcurl options that allow a user to stop a transfer that goes below a certain transfer speed threshold during a given time). I had added a way to disable the internal progress meter functionality, but obviously not done a good enough job!

The breakage proved we don’t have proper tests for this functionality. I reverted the commit immediately to bring back the feature, and when now I go back to fix this and land a better fix soon, I now also know that I need to add tests to verify.

multi: track users of a socket better

Not too long ago I found and fixed a pretty serious flaw in curl’s HTTP/2 code which made it deal with multiplexed transfers over the same single connection in a manner that was far from ideal. When fixed, it made curl do HTTP/2 better in some circumstances.

This improvement ended up proving itself to have a few flaws. Especially when the connection is closed when multiple streams are done over it. This bug-fix now makes curl closing down such transfers in a better and cleaner way with fewer “loose ends”.

parse_proxy: use the IPv6 zone id if given

One more zone id fix that I didn’t get around to land in 7.65.0 has now landed: specifying a proxy with a URL that includes an IPv6 numerical address and a zone id – now works.

connection “bundles” on same host but different ports

Internally, libcurl collects connections to a host + port combination in a “bundle” (that’s just a term used for this concept internally). It does this to count number of connections to this combination and enforce limits etc. It is only used a bit for controlling when multiplexing can be done or not on this host.

Due to a regression, probably added already back in 7.62.0, this logic always used the default port for the protocol instead of the actual port number used in the given URL! An application that for example did parallel HTTP transfers to the hostname “example.org” on both port 80 and port 81, and used HTTP/1 on one of the ports and HTTP/2 on the other would be totally mixed up by curl and cause transfer failures.

But not anymore!

Coming up

This patch release was not planned. We will give this release a few days to stew and evaluate the situation. If we keep getting small or big bugs reported, we might not open the feature window at all in this release cycle and instead just fix bugs.

Ideally however, we’ve now fixed the most pressing ones and we can now move on and follow our regular development process. Even if we have, the feature window for next release will be open during a shorter period than normal.

curl can be downloaded from the wolfSSL download page located here: https://www.wolfssl.com/download/
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's common to hear the term asymmetric or symmetric cryptography but what does this actually mean? A brief explanation is that asymmetric cryptography is cryptography that has two keys which is why it is also called public-key cryptography. Both keys in the algorithm are linked to each other in a mathematical way, which allows for using EPKE (Enveloped Public Key Encryption) in the common TLS connection. EPKE using an asymmetric cryptography algorithm allows for security from the message being read and from it being tampered with.

The wolfSSL embedded SSL/TLS library supports several different asymmetric algorithms, including RSA, ECC, and Ed25519!

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

wolfBoot is wolfSSL's own implementation of a secure bootloader that leverages wolfSSL's underlying wolfCrypt module to provide signature authentication for the running firmware.

The role of a secure bootloader is to effectively prevent the loading of malicious or unauthorized firmware on the target. Additionally, wolfBoot provides a fail-safe update mechanism, that can be interrupted at any time, and resumed at next boot.

wolfBoot is designed to be a portable, OS-agnostic, secure bootloader solution for all 32-bit microcontrollers, relying on wolfCrypt for firmware authentication.

Due to its minimalist design and the tiny Hardware Abstraction Layer (HAL) API, wolfBoot is completely independent of any OS or bare-metal application, and can be easily ported and integrated into existing embedded software solutions.

wolfBoot provides the basis for secure firmware update (OTA) management at boot time, cutting down the development effort needed to implement and validate the required mechanisms to handle the updates. It reduces the development effort to just receiving the image using a secure channel within the application/OS. We recommend using wolfSSL to encrypt the firmware transfer over TLS, to avoid eavesdropping. Once the image is transferred and stored into the update partition, wolfBoot takes care of the update procedure at the next boot.

Remote updates that would lead to a faulty firmware are automatically reverted by wolfBoot after the first 'test' boot, by restoring the original firmware image whenever the update has failed to boot properly. This mechanism protects the target device from accidental updates on the field.

wolfBoot can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/

More about boot loaders can be found here: https://en.wikipedia.org/wiki/Booting#BOOT-LOADER
More about wolfSSL: https://www.wolfssl.com/products/wolfssl/
More about wolfCrypt: https://www.wolfssl.com/products/wolfCrypt/

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

With the release of wolfSSL 4.0.0, the wolfSSL team has also released a new product: the wolfSSL FIPS Ready library. This product features new, state of the art concepts and technology. In a single sentence, wolfSSL FIPS Ready is a testable and free to download open source embedded SSL/TLS library with support for FIPS validation, with FIPS enabled cryptography layer code included in the wolfSSL source tree. To further elaborate on what FIPS Ready really means, you do not get a FIPS certificate and you are not FIPS approved. 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 (POST).

FIPS validation is a government certification for cryptographic modules that states that the module in question has undergone thorough and rigorous testing to be certified. FIPS validation specifies that a software/encryption module is able to be used within or alongside government systems. The most recent FIPS specification is 140-2, with various levels of security offered (1-5). Currently, wolfCrypt has FIPS 140-2 validation with certificates #2425 and #3389. When trying to get software modules FIPS validated, this is often a costly and time-consuming effort and as such causes the FIPS validated modules to have high price tags.

Since the majority of wolfSSL products use the wolfCrypt encryption engine, this also means that if wolfSSH, wolfMQTT (with TLS support), wolfBoot, and other wolfSSL products in place can be tested FIPS validated code with their software before committing.

wolfSSL FIPS Ready can be downloaded from the wolfSSL download page, here: https://www.wolfssl.com/download/

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 National Institute of Standards and Technology (NIST) has completed the validation of the wolfCrypt module version 4 for an updated Federal Information and Processing Standards (FIPS) 140-2 certificate in addition to its previous FIPS 140-2 certificate. This new certificate includes updated and more secure algorithms added to the wolfCrypt module's boundary, some of which are listed further below.

FIPS 140-2 is a government standard that specifies a software module is compatible and allowed to be used in government systems. This includes such areas as drone software, government databases, and other high-security/high-power uses.

The new FIPS 140-2 validation has certificate #3389. The Operating Environments (OEs) tested are Ubuntu Linux (16.04) and Windows 10 on Intel Core i5 processors. Full details about the OEs can be found on the CSRC certificate page. Additionally, the certificate also includes the following algorithms: 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.

For more information about wolfSSL, wolfCrypt, or our FIPS 140-2 validations, please view our resources below.

• wolfSSL FIPS page: https://www.wolfssl.com/license/fips/
• wolfSSL product page: https://www.wolfssl.com/products/wolfssl/
• wolfCrypt product page: https://www.wolfssl.com/products/wolfcrypt/

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

wolfBoot is wolfSSL’s portable, OS-agnostic, secure bootloader solution for 32-bit microcontrollers, relying on wolfCrypt for firmware authentication.  wolfBoot also provides firmware update mechanisms.

MISRA C is a set of rules and guidelines for C code targeting Automotive applications.  The focus of the guidelines is on security and safety.

wolfSSL is considering making wolfBoot compliant with the MISRA C standard.  Please let us know if you have an interest in testing this combination.

For questions about wolfBoot or using wolfSSL technology with MISRA C.

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

Download wolfBoot here: https://www.wolfssl.com/download/
More information about MISRA C can be found here: https://misra.org.uk

With every release of the wolfSSL embedded SSL/TLS library, there are multiple feature additions, port additions, and updates. One of the ports that was added to the wolfSSL library recently was a port to Contiki! You can checkout the changes for Contiki in PR #2500 against the contiki-os/contiki github repository!

Contiki is an open source operating system for the Internet of Things. It connects tiny low-cost, low-power microcontrollers to the Internet. Contiki is a perfect match for wolfSSL, which was built for use on embedded and resource-constrained devices with portability in mind. In addition to being highly portable, wolfSSL provides support for the latest and greatest version of the TLS protocol, TLS 1.3! Using the wolfSSL port with your device running Contiki will allow your IoT device to connect to the internet in one of the most secure ways possible.

The Contiki port in wolfSSL is activated by using the "WOLFSSL_CONTIKI" macro when compiling wolfSSL. An example of this on embedded devices would be placing WOLFSSL_CONTIKI into a user_setttings.h file, or by including the option CPPFLAGS="-DWOLFSSL_CONTIKI" if compiling wolfSSL by using autotools.

For more information, please contact facts@wolfssl.com.

Resources
The most recent version of wolfSSL can be downloaded from our download page, here: https://www.wolfssl.com/download/
wolfSSL support for TLS 1.3: https://www.wolfssl.com/docs/tls13/
Contiki OS homepage: http://www.contiki-os.org

We have had a few inquiries about using the wolfSSL embedded SSL/TLS library with secure web sockets lately, and wanted to inform our community that the libwebsockets team has successfully tested with wolfSSL through use of wolfSSL's OpenSSL compatibility layer. The wolfSSL compatibility layer allows for drop-in replacement of OpenSSL resulting in not only a much smaller footprint but very competitive speeds when using the Single Precision Math and/or other optimizations supported by wolfSSL (contact facts@wolfssl.com for more info on Single Precision and other cryptographic optimizations). The libwebsockets team has posted a basic guide for getting started with wolfSSL at the following link: https://libwebsockets.org/lws-api-doc-master/html/md_READMEs_README_8build.html#wolf.

For more information about wolfSSL or one of its products, contact us at facts@wolfssl.com, or call us at +1 425 245 8247.

author: Daniel Stenberg

After another eight week cycle was been completed, curl shipped a new release into the world. 7.65.0 brings some news and some security fixes but is primarily yet again a set of bug-fixes bundled up. Remember 7.64.1?

As always, download it straight from curl.haxx.se!

One fun detail on this release: we have 500 less lines of source code in the lib/ directory compared to the previous release!

Things that happened in curl since last release:

• we announced a new Bug Bounty program and already paid the first rewards
• curl up 2019 happened and was awesome
• at wolfSSL we announced the tinycurl effort
• we’re running the annual curl survey right now
• we’ve welcomed new sponsors

Numbers

the 181st release
3 changes
56 days (total: 7,733)
119 bug fixes (total: 5,148)
215 commits (total: 24,326)
0 new public libcurl function (total: 80)
1 new curl_easy_setopt() option (total: 267)
0 new curl command line option (total: 221)
50 contributors, 24 new (total: 1,953)
32 authors, 12 new (total: 681)
2 security fixes (total: 89)
350 USD paid in Bug Bounties

News

1. libcurl has deprecated support for the global DNS cache.
2. Pipelining support is now completely removed from curl.
3. CURLOPT_MAXAGE_CONN is a new option that controls how long to keep a live connection in the connection cache for reuse.

Security

This release comes with fixes for two separate security problems. Both rated low risk. Both reported via the new bug bounty program.

CVE-2019-5435 is an issue in the recently introduced URL parsing API. It is only a problem in 32 bit architectures and only if an application can be told to pass in ridiculously long (> 2GB) strings to libcurl. This bug is similar in nature to a few other bugs libcurl has had in the past, and to once and for all combat this kind of flaw libcurl now (in 7.65.0 and forward) has a “maximum string length” limit for strings that you can pass to it using its APIs. The maximum size is 8MB. (The reporter was awarded 150 USD for this find.)

CVE-2019-5436 is a problem in the TFTP code. If an application decides to uses a smaller “blksize” than 504 (default is 512), curl would overflow a buffer allocated on the heap with data received from the server. Luckily, very few people actually download data from unknown or even remote TFTP servers. Secondly, asking for a blksize smaller than 512 is rather pointless and also very rare: the primary point in changing that size is to enlarge it. (The reporter was awarded 200 USD for this find.)

Bug-fixes

Over one hundred bug-fixes landed in this release, but some of my favorites from release cycle include…

mark connection for close on TLS close_notify

close_notify is a message in the TLS protocol that means that this connection is about to close. In most circumstances that message doesn’t actually provide information to curl that is needed, but in the case the connection is closed prematurely, understanding that this message preceded the closure helps curl act appropriately. This change was done for the OpenSSL backend only as that’s where we got the bug reported and worked on it this time, but I think we might have reasons to do the same for other backends going forward!

show port in the verbose “Trying …” message

The verbose message that says “Trying 12.34.56.78…” means that curl has sent started a TCP connect attempt to that IP address. This message has now been modified to also include the target port number so when using -v with curl 7.65.0, connecting to that same host for HTTPS will instead say “Trying 12.34.56.78:443…”.

To aid debugging really. I think it gives more information faster at a place you’re already looking.

new SOCKS 4+5 test server

The test suite got a brand new SOCKS server! Previously, all SOCKS tests for both version 4 and version 5 were done by firing up ssh (typically openssh). That method was decent but made it hard to do a range of tests for bad behavior, bad protocol replies and similar. With the new custom test server, we can basically add whatever test we want and we’ve already extended the SOCKS testing to cover more code and use cases than previously.

SOCKS5 user name and passwords must be shorter than 256

curl allows user names and passwords provided in URLs and as separate options to be more or less unrestricted in size and that include if the credentials are used for SOCKS5 authentication – totally ignoring the fact that the protocol SOCKS5 has a maximum size of 255 for the fields. Starting now, curl will return an error if the credentials for SOCKS5 are too long.

Warn if curl and libcurl versions do not match

The command line tool and the library are independent and separable, as in you can run one version of the curl tool with another version of the libcurl library. The libcurl API is solid enough to allow it and the tool is independent enough to not restrict it further.

We always release curl the command line tool and libcurl the library together, using the same version number – with the code for both shipped in the same single file.

There should rarely be a good reason to actually run curl and libcurl with different versions. Starting now, curl will show a little warning if this is detected as we have learned that this is almost always a sign of an installation or setup mistake. Hopefully this message will aid people to detect the mistake earlier and easier.

Better handling of “–no-” prefixed options

curl’s command line parser allows users to switch off boolean options by prefixing them with dash dash no dash. For example we can switch off compressed responses by using “–no-compression” since there regular option “–compression” switches it on.

It turned out we stripped the “–no-” thing no regarding if the option was boolean or not and presumed the logic to handle it – which it didn’t. So users could actually pass a proxy string to curl with the regular option “–proxy” as well as “–no-proxy”. The latter of course not making much sense and was just due to an oversight.

In 7.65.0, only actual boolean command line options can be used with “–no-“. Trying it on other options will cause curl to report error for it.

Add CURLUPART_ZONEID to the URL API

Remember when we added a new URL parsing API to libcurl back in 7.62.0? It wasn’t even a year ago! When we did this, we also changed the internals to use the same code. It turned out we caused a regression when we parsed numerical IPv6 addresses that provide the zone ID within the string. Like this: “https://[ffe80::1%25eth0]/index.html”

Starting in this release, you can both set and get the zone ID in a URL using the API, but of course setting it doesn’t do anything unless the host is a numeric IPv6 address.

parse proxy with the URL parser API

We removed the separate proxy string parsing logic and instead switched that over to more appropriately use the generic URL parser for this purpose as well. This move reduced the code size, made the code simpler and makes sure we have a unified handling of URLs! Everyone is happy!

longer URL schemes

I naively wrote the URL parser to handle scheme names as long as the longest scheme we support in curl: 8 bytes. But since the parser can also be asked to parse URLs with non-supported schemes, that limit was a bit too harsh. I did a quick research, learned that the longest currently registered URI scheme is 36 characters (“microsoft.windows.camera.multipicker”). Starting in this release , curl accepts URL schemes up to 40 bytes long.

Coming up next

There’s several things brewing in the background that might be ready to show in next release. Parallel transfers in the curl tool and deprecating PolarSSL support seem likely to happen for example. Less likely for this release, but still being worked on slowly, is HTTP/3 support.

We’re also likely to get a bunch of changes and fine features we haven’t even thought about from our awesome contributors. In eight weeks I hope to write another one of these blog posts explaining what went into that release…

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