RECENT BLOG NEWS

The wolfSSL lightweight SSL/TLS library now supports TLS 1.3 (Draft 18) on both the client and server side!

A BETA release of wolfSSL (wolfSSL 3.11.1) is available for download from our download page. This release is strictly BETA, and designed for testing and user feedback. Users and customers wanting a stable and production-ready version of wolfSSL should remain on version 3.11.0.

To compile this release with TLS 1.3 support, use the “–enable-tls13” ./configure option:

$ unzip wolfssl-3.11.1-tls13-beta.zip
$ cd wolfssl-3.11.1-tls13-beta
$ ./configure –enable-tls13
$ make

wolfSSL has two new client/server methods, which can be used to specify TLS 1.3 during creation of a wolfSSL context (WOLFSSL_CTX):

WOLFSSL_METHOD *wolfTLSv1_3_server_method(void);
WOLFSSL_METHOD *wolfTLSv1_3_client_method(void);

The wolfSSL example client and server can be used to easily test TLS 1.3 functionality with wolfSSL. For example, to connect the wolfSSL example client and server to each other using TLS 1.3 and the TLS13-AES128-GCM-SHA256 cipher suite, use the “-v” option with “4” to specify TLS 1.3, and the “-l” option to specify the cipher suite:

$ ./examples/server/server -v 4 -l TLS13-AES128-GCM-SHA256
$ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA256

Alternatively, the example client can be used to connect to an external server. For example, to connect to the wolfSSL website with TLS 1.3:

$ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA256 -h www.wolfssl.com -p 443 -g -A ./certs/wolfssl-website-ca.pem

In this command, “-h” specifies the host, “-p” the port, “-g” causes the client to send an HTTP GET request, and “-A” specifies the CA certificate used to authenticate the server.

wolfSSL currently supports the following TLS 1.3 cipher suites:

TLS13-AES128-GCM-SHA256
TLS13-AES256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES128-CCM-SHA256
TLS13-AES128-CCM-8-SHA256

Please send any comments or feedback on wolfSSL’s TLS 1.3 support to support@wolfssl.com. Thanks!

wolfSSL 3.11.0 is now available for download! This release contains bug fixes, exciting new features, and includes fixes for several security vulnerabilities (5 low and 1 medium level).

Continue reading below for a summary of the features and fixes included in this release.

Vulnerability Fixes

This release fixes three LOW level vulnerabilities reported by Yueh-Hsun Lin and Peng Li from KNOX Security, Samsung Research America, including:

1.  A fix for out-of-bounds memory access in wc_DhParamsLoad() when GetLength() returns a zero. Before this fix there was a case where wolfSSL would read out of bounds memory in the function wc_DhParamsLoad().
2. A fix for wc_DhAgree() where a malformed key could be accepted by the function.
3. A fix for a double free case when adding a CA cert into an X509_STORE.

One LOW level vulnerability was fixed in relation to memory management with the static memory feature enabled. By default static memory is disabled. Thanks to GitHub user hajjihraf for reporting this.

One LOW level vulnerability was fixed for an out-of-bounds write in the function wolfSSL_X509_NAME_get_text_by_NID(). This function is not used by TLS or crypto operations but could result in a buffer out of bounds write by one if called explicitly in an application. Discovered by Aleksandar Nikolic of Cisco Talos (http://talosintelligence.com/vulnerability-reports/).

One MEDIUM level vulnerability was fixed in relation to checks on a certificate signature. There was a case in release versions 3.9.10, 3.10.0 and 3.10.2 where a corrupted signature on a peer certificate would not be properly flagged. Thanks to Wens Lo, James Tsai, Kenny Chang, and Oscar Yang at Castles Technology.

NGINX support

We are excited to announce support for building the NGINX web server with wolfSSL!  Nginx and wolfSSL make a likely pairing because they are both lean, compact, fast, and scale well under high volumes of connections.

HAproxy support

wolfSSL now supports being compiled into the HAproxy load balancer!  HAproxy offers high availability, load balancing, and proxying for TCP and HTTP-based applications.

Intel QuickAssist Asynchronous Support

We have added support to wolfSSL for Intel QuickAssist asynchronous crypto support.  More complete details can be found in our recent blog post.

Performance Enhancements

– A 51-bit implementation of Curve25519 has been added, increasing performance on systems that have 128 bit types available.
– Heap usage reductions for users using the fastmath library (USE_FAST_MATH) when not using ALT_ECC_SIZE.

Updated Software Ports

Existing wolfSSL software ports have been updated, including:

– wpa_supplicant
– stunnel 5.40
– Improvements to uTKernel port (WOLFSSL_uTKERNEL2)
– Updated Arduino script to handle recent files and additions
– Fixes for building CRL on Windows

And, we have added one new port as well:

– New port to the tenAsys INtime RTOS

Updated Hardware Ports

– Added an NXP Hexiwear example, located in the “IDE/HEXIWEAR” directory.
– Fixes for STM32 hardware crypto acceleration.  More details on using wolfSSL with STM32 platforms can be found here.

Protocol and Cipher Suite Updates

We have made several changes that affect the SSL/TLS/DTLS protocol level and cipher suite support, including:

– A fix for interoperability with ChaCha20-Poly1305 suites using older draft versions
– A DTLS update to allow multiple handshake messages in one DTLS record
– A new option to allow SHA1 with TLS 1.2 for IIS compatibility (WOLFSSL_ALLOW_TLS_SHA1)
– A fix to prevent send session IDs on the server side if the session cache is off unless we`re echoing session ID as part of session tickets
– A small change to the max PSK identity buffer to account for an identity length of 128 characters
– Fixes for ensuring all default ciphers are setup correctly (see PR #830)
– Addition of wolfSSL_write_dup() to create a write only WOLFSSL object for concurrent access
– Fixes for TLS Elliptic Curve selection on private key import
– Improvements to the TLS layer context handling for switching keys and certs
– Addition of support for inline CRL lookup when HAVE_CRL_IO is defined
– Addition of a sanity check that subject key identifier is marked as non-critical, and a check that no policy OIDS appear more than once in the cert policies extension. Thanks to the report from Professor Zhenhua Duan, Professor Cong Tian, and Ph.D candidate Chu Chen from Institute of Computing Theory and Technology (ICTT) of Xidian University, China. Profs. Zhenhua Duan and Cong Tian are supervisors of Ph.D candidate Chu Chen.

Crypto Additions and Modifications

We have made several changes that affect our underlying wolfCrypt cryptography library, including:

– Updates and refactoring to ASN1 parsing functions
– Additional PKS#7 support for SignedData with ECDSA
– Fixes to RNG with speedups for Intel RDRAND and RDSEED
– Improved performance for Intel RDRAND, using full 64-bit output
– Addition of a new “–enable-intelrand” option to indicate use of RDRAND preference for RNG source
– Removal of RNG ARC4 support
– ECC helper functions to get size and ID from a curve name
– ECC private key only import and export functions
– ECC Cofactor DH (ECC-CDH) support
– PKCS#8 create function
– Normal math speed-up where to defer allocation on mp_int until mp_grow
– A sanity check for minimum authentication tag size with AES-GCM. Thanks to Yueh-Hsun Lin and Peng Li at KNOX Security at Samsung Research America for suggesting this

Testing and Warning Fixes

– Warnings reported by Coverity Scan have been fixed, bringing you an even more well-tested wolfSSL SSL/TLS implementation.  For all of the testing we currently do, see our testing blog post.
– Additional testing and warnings have been fixed for FreeBSD builds on big endian PowerPC systems.
– Extended testing code coverage in the wolfCrypt test application (test.c) that comes bundled with wolfSSL.

If you have any questions about the new release, or using wolfSSL in your project, please contact us at facts@wolfssl.com

We have been working within OpenEmbedded and the Yocto Project to develop an Open Source SSL/TLS layer designed for incorporating wolfSSL into custom Linux builds for embedded systems. meta-wolfssl contains three completed recipes including the wolfSSL library as well as the wolfCrypt test and benchmark executables. You can now test and send information quickly and securely through your embedded device using our portable and lightweight SSL/TLS library.

These recipes can be easily incorporated into any bitbake build, specifically through the use of the OpenEmbedded and Yocto Project utilities. For our original construction, we ran a custom version of core-image-sato (a mobile image platform) on the Minnowboard.

The meta-wolfssl github page includes detailed instructions for installing any of these recipes in your build image. Check back for future updates regarding meta-wolfssl and OpenEmbedded/Yocto. If you have any questions regarding adding wolfSSL to your OpenEmbedded/Yocto projects, feel free to contact us at support@wolfssl.com.

Hi!  We have been asked a number of times about wolfSSL integration with the Nginx web server.  If you are not familiar with Nginx, it is a high performance, high concurrency web server that is becoming extremely popular these days.  You can learn more about Nginx at nginx.com.

Nginx and wolfSSL make a likely pairing because they are both lean, compact, fast, and scale well under high volumes of connections.  The big news today is that wolfSSL is now working with Nginx! We have added a new configure option “–enable-nginx” which will compile the wolfSSL libraries with NGINX support. For more info please contact us today facts@wolfssl.com!

Hi! Are you interested in using wolfSSL with the Contiki OS? If so, let us know at facts@wolfssl.com! The wolfSSL lightweight SSL/TLS library is a perfect match for resource-constrained embedded IoT devices. wolfSSL currently supports up to TLS 1.2 and DTLS 1.2, with TLS 1.3 support up and coming.

Contiki, as described by their website, is “an open source operating system for the Internet of Things. Contiki connects tiny low-cost, low-power microcontrollers to the Internet. Contiki is a powerful toolbox for building complex wireless systems.”

As those microcontrollers are connecting to the Internet, secure connectivity with SSL/TLS/DTLS is important. We look forward to hearing your thoughts about using wolfSSL with Contiki!

wolfSSL recently completed a port to Tenasys INTime RTOS! You can read more in the press release from Tenasys here: Secured INtime system traffic!

Tenasys is using wolfSSL to secure their networked real-time systems and wolfSSL is happy to be integrated into the INTime networking stack which allows us to provide world renowned security to INTime SDK consumers. If you have any questions about this please contact wolfSSL: facts@wolfssl.com

Reference: https://www.pressebox.com/pressrelease/tenasys-europe-gmbh/20-years-of-commercial-usage-TenAsys-Corp-shows-INtime-real-time-OS-at-Embedded-World-2017/boxid/842331

wolfSSL has support for The Real-time Operating system Nucleus’ (TRONs’) Micro T-Kernel or (uT-Kernel / ?T-Kernel). Users can define “WOLFSSL_uTKERNEL2” in their project settings to take advanatage of wolfSSL support for this popular T-Engine Forum integrated project!

If you have any questions please contact wolfSSL: facts@wolfssl.com!

Tired of using OpenSSL? Recently wolfSSL has been expanding our compatibility layer, which means that it soon will be even easier to replace OpenSSL with wolfSSL in existing projects. In some cases the replacement can be as easy as including and linking to a wolfSSL library that has been compiled with –enable-opensslextra.

For more information about the wolfSSL or the compatibility layer contact us at facts@wolfssl.com.

Curious about new features and additions to wolfSSL technologies for the coming year?  Some items on our current roadmap include increasing performance through hardware acceleration and instruction level tuning, resource reduction tuning, and increasing our Async Crypto support to other projects like nginx.  Our TLS 1.3 draft support is ready for testing and should the specification go final our release will be one of the first.

In terms of new environments we’ll have more FIPS platforms, more FIPS algorithms, easier integration with event programming, Data plane development support, more language wrappers, SGX support at the TLS level, and more Open Source project plugins including HAProxy, nginx, and wpa_supplicant.

Look for product improvements to wolfMQTT, wolfSSH, and wolfCrypt.  We also anticipate offering our testing and security audit programs as services.  Keep an eye out for connected home white papers and case studies.  Something we missed, or something you would like to see on our roadmap?  Please let us know.

Or feel free to visit our website at wolfssl.com or email us at facts@wolfssl.com.

Sometimes the consumers of the wolfSSL Embedded TLS library are curious about our internal process for handling vulnerability reports.  The first thing our users need to know is that wolfSSL takes every vulnerability report seriously!  We currently maintain a mean time to verification of about 1.5 hours.  Our mean time to achieve a fix is about 12 hours.  As most of our readers know, not all CVE’s are created equally, so our fixes can take anywhere from 24 minutes to 24 hours.

The final statistic we can share is one that we are particularly proud of:  Our mean time between a report and a release over the last 3 years is 38 hours!  We believe this is an industry leading number, and one that we will strive to maintain and even improve!

Break-down of wolfSSL vulnerability response procedures:

#1 – (45 – 120 minutes)

– Support staff de-prioritizes all support to confirm vulnerability exists

– Support staff makes any necessary modifications to provided test code to make it build out-of-the-box for engineering team

– Support staff creates README for engineering team to be able to re-produce in 10 minutes or less

– As soon as validated and tests streamlined alert is sent to engineering team along with report and test case

#2 – (20 minutes – 1 day)

– Engineering team fixes the issue and opens a pull request

– Multiple engineers review fix

#3 – (1 hour)

– Jenkins automated integration server tests fix

#4 – (1 hour)

– Senior Engineer reviews Jenkins results and suggested fix

#5 – (N/A)

– repeat steps #2 – #4 as necessary

#6 – (N/A)

– Fix is merged

#7 (1 day)

– Release process started

– New GPL licensed release posted to website

– Commercial Releases sent to customers