RECENT BLOG NEWS

wolfSSL is at Embedded Tech West this year! ET & IoT Technology West features leading Edge technology and solutions. For 2019, ET West will be held in Osaka, Japan.

Where Embedded Tech West will be held for 2019:
Venue: Grand Front Osaka - KNOWLEDGE CAPITAL Congrès Convention Center
wolfSSL Booth #: H-06
When: June 12-13
Directions: http://www.congre-cc.jp/access/

Stop by our booth to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL team, or to get some free stickers and swag!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about Wireless IoT can be found here: http://www.jasa.or.jp/etwest/

Benchmark values of the wolfSSL embedded SSL/TLS library running on Xilinx boards, including the ZCU102, have been collected and are up for viewing. Our friends over at Xilinx have a white paper posted that goes into detail about the benchmark values here https://www.xilinx.com/support/documentation/white_papers/wp512-accel-crypto.pdf. This shows how much faster applications can perform secure operations when incorporating the hardware acceleration available on Xilinx devices. It also gives a demonstration of the performance trade-offs when choosing FreeRTOS versus an embedded Linux OS.

Additionally, Xilinx has also posted their own evaluation of the cryptographic performance gains that can be achieved by using wolfSSL in conjunction with their own hardware. Their post can be viewed here: https://forums.xilinx.com/t5/Adaptable-Advantage-Blog/Increase-your-products-cryptographic-performance-by-using/ba-p/978932

For questions about building wolfSSL to use hardware acceleration or other general inquiries about wolfSSL, please contact us at facts@wolfssl.com.

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/

wolfSSL is at this month's RISC-V workshop! RISC-V is a free and open ISA enabling a new era of processor innovation through open standard collaboration. Founded in 2015, the RISC-V Foundation comprises more than 235 members building the first open, collaborative community of software and hardware innovators powering innovation at the edge forward. For June, this RISC-V workshop will be held in Zurich, Switzerland.

Where RISC-V will be held for 2019:
Venue: ETH Zurich
When: June 11-13
Directions: https://tmt.knect365.com/risc-v-workshop-zurich/plan-your-visit

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, or to meet the wolfSSL team! Feel free to say hello!

Additionally, wolfSSL software engineers David Garske and Daniele Lacamera will be presenting a talk on secure booting with RISC-V! Their talk will cover the porting of wolfBoot to RISC-V for implementing a secure bootloader and firmware update mechanism, and will be held at 1:55pm on June 11th.

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about RISC-V can be found here: https://riscv.org/events/upcoming-events/.

wolfSSL is at TU Automotive this year! TU-Automotive Detroit is the world's largest auto tech conference & exhibition, shaping the future of connected automobiles. For 2019, TU Automotive will be held in Novi, MI.

Where TU Automotive will be held for 2019:
Venue: Suburban Collection Showplace
Booth #: A33
When: June 5, 6
Directions: https://automotive.knect365.com/tu-auto-detroit/plan-your-visit

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, or to meet the wolfSSL team! Feel free to say hello!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about TU Automotive  can be found here: https://automotive.knect365.com/tu-auto-detroit/.

wolfSSL is at RTCA this year! RTCA’s annual event attracts hundreds of executives from FAA, airlines, airports, manufacturers, service providers, UAS, aviation associations, general aviation and businesses from the US and around the world to examine current and emerging issues facing the aviation community. For 2019, RTCA will be held in Crystal City, VA.

Where RTCA will be held for 2019:
Venue: Hyatt Regency Crystal City
When: June 5
Directions: https://www.rtca.org/content/hoteltravel

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, or to meet the wolfSSL team! Feel free to say hello!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about RTCA can be found here: https://www.rtca.org/content/symposium-overview.

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!

For more information about asymmetric cryptography used in wolfSSL contact us at facts@wolfssl.com.

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/

Contact facts@wolfssl.com for any questions or for more information

wolfSSL is at NXP Connects this year! NXP Connects represents the energy, depth, and scope of a large-scale conference designed in a concentrated format to offer a more personalized experience. Combining a wide range of technical sessions, live-demonstrations, panel discussions and networking opportunities at a regional level, attendees can focus their time on embedded solutions that specifically address their current and future designs. For 2019, NXP Connects will be held in Santa Clara, CA.

Where NXP Connects will be held for 2019:
Venue: Hyatt Regency Santa Clara and Convention Center
When: June 12-13
Directions: https://www.hyatt.com/en-US/hotel/california/hyatt-regency-santa-clara/clara/maps-parking-transportation

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, or to meet the wolfSSL team! Feel free to say hello!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about Wireless IoT can be found here: https://www.nxp.com/support/training-events/nxp-connects:NXP-CONNECTS

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/

For more information about wolfSSL and its FIPS Ready initiative, please contact facts@wolfssl.com.