RECENT BLOG NEWS

Recently we announced availability of TLS v1.3 in wolfSSL. There are many benefits in changing to the newest version of the TLS specification.

One significant difference you will notice is the reduced number of round-trips when performing a full handshake. Older versions of the TLS protocol require two complete round-trips before the client sends the application data. With TLS v1.3 only 1 round-trip is required! Additionally, the server can send application data in response to the clients first handshake message! This means network latency has less impact on the time required to establish a secure connection.

Another difference is the way session resumption works in TLS v1.3. Previous versions of TLS have the client send a session id which the server has to lookup in its cache. If there was a match then they used the same security parameters. This is a very simplistic mechanism that requires sharing of state on servers.

TLS v1.3 has made significant improvements by re-purposing the ticketing system tacked onto older versions of TLS. The server sends the client a new session ticket after the handshake is complete. This ticket, a blob of data to the client, can be a database lookup key like the old session id. Alternatively, it can be a self-encrypted and self-authenticated value that contains the data for the previous connection. This means the server can be stateless!

Finally, the specification has been evaluated by cryptographic experts in efforts to prove the security of the protocol. While no security proof is perfect, the previous attacks on renegotiation, protocol version downgrading, compression, CBC and padding have been mitigated and the protocol is generally more resistant to attack.

For more details on using TLS v1.3 with wolfSSL, please contact us at facts@wolfssl.com

We are considering adding support for the Mongoose Web Server.  If you are interested in using CyaSSL with Mongoose please let us know at info@yassl.com.

Did you know that wolfSSL supports OCSP Stapling (Certificate Status Request TLS Extension) described in RFC6066 and OCSP Stapling v2 (Certificate Status Request TLS Extension v2) described in RFC6961?

And what benefits can we get out of it?

Without OCSP stapling, SSL/TLS clients needs to spend extra resources on a second socket to communicate with an OCSP Responder in order to validate the server`s certificates using OCSP. Also, the OCSP Responder is likely to be hit by enormous volumes of OCSP requests if a certificate is issued to a high traffic server, introducing a significant cost for the certificate authority.

OCSP stapling allows the server to bear the resource cost involved in providing OCSP responses by appending a time-stamped OCSP response to the initial SSL/TLS Handshake, eliminating the need for clients to contact the OCSP Responder. This way, a single OCSP response can be reused util it expires, forcing the server to get a new OCSP response from the OCSP Responder.

OCSP Stapling v2 defines a new extension, “status_request_v2”, with an extended format that allows the client to indicate support for multiple status request methods.

For more details on using OCSP Stapling in wolfSSL, please refer to the wolfSSL Manual or contact us at facts@wolfssl.com

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 websitewith 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!

wolfMQTT v0.13 is now available for download. This release contains fixes for non-blocking and Arduino.

The wolfMQTT client is a lightweight protocol used commonly in the IoT space and is a pub/sub model. It is written in C from scratch and is based on the MQTT v3.1.1 specification. As a result the code is compact (~4KB) and clean. We’ve taken great care to explicitly check all parameters and input data to ensure reliable and secure operation. The client also integrates with our wolfSSL client to provide TLS for MQTT, which is required for AWS and Azure.

We have examples for connecting to:
* Amazon Web Services (AWS)
* Microsoft Azure IoT Hub
* Firmware Update over MQTT
* Generic MQTT client

The examples support using various operating systems and network stacks such as Linux/Mac/Windows/FreeRTOS/MQX. The wolfMQTT library uses callbacks for the networking so you can implement it for any two of communication interface. We even have an example template for using a UART via the callbacks.

Planned upcoming features:
* Multi-threaded support
* Android and iOS examples
* MQTT-SN (sensor network spec that reduces protocol overhead).

If you have any questions or would like more information please email us at facts@wolfssl.com.

Moises Guimaraes of the wolfSSL team will be in Prague June 8th to 10th, talking at PyCon CZ about our wolfCrypt Python module and basic cryptography principles. See his talk summary at https://cz.pycon.org/2017/speakers/detail/talk/28/#main.

Register today for PyCon CZ at https://cz.pycon.org/2017/#tickets. If you are already planning on attending, please chat with us about cryptography, SSL/TLS, and hardware encryption.

If you would like to set up a specific meeting time, please email Moises at moises@wolfssl.com.

To stay up to date with what is happening with wolfSSL, follow our blog.

We look forward to hearing from you!

Hi!  Are you interested in using wolfSSL with OpenVPN?  If so, let us know at facts@wolfssl.com or post a reply to this forum topic: https://www.wolfssl.com/forums/topic999-using-wolfssl-with-openvpn.html

The wolfSSL lightweight SSL/TLS library is nice for reduced overhead and maximum throughput in addition to supporting cutting edge curves and cipher suites!  wolfSSL currently supports up to TLS 1.3 and DTLS 1.2 and offers leading support in the industry!

OpenVPN, as described by their website, is “an open source virtual private network solution that has established itself as the defacto standard”.

We look forward to hearing your thoughts about using wolfSSL with OpenVPN!

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.