Category: Uncategorized

It has been 4 years since the TLS v1.3 specification came out with Draft 1 and it looks like it has been finalized! With the release of Draft 24 the last of the WG comments have been addressed. Now the IESG will review the document and it is expected that it will soon be ratified as an RFC.

wolfSSL has updated its TLS v1.3 code to include support for Draft 22 and 23. Draft 24 is not significantly different and with the highly anticipated release of the RFC, we are looking forward to finalizing the TLS v1.3 code.

The last time we discussed TLS v1.3 the specification was at Draft 21. Since then a number of changes have been made to deal with middlebox incompatibilities.

Middleboxes are devices that sit between the client and the server that typically inspect, filter or act as a proxy. They are a necessary part of the Internet ecosystem. Inspection middleboxes are used to monitor network traffic and to collect statistics. Filters attempt to detect and remove undesirable network traffic that is malformed or malicious. Proxy-servers are used to terminate TLS connections to better manage the network traffic and spread load.

Middleboxes include embedded devices that are updated by changes to the firmware. Therefore updates are seldom made and the TLS v1.3 specification had to be modified to work with the deployed systems.

Mozilla performed a customer test with their browser connecting to a controlled website supporting Draft 18. The results (https://www.ietf.org/mail-archive/web/tls/current/msg25091.html) were that TLS v1.3 Draft 18 failed 2.91% of the time compared to TLS v1.2 failure rate of 1.58%. This was statistically significant. After some compatibility changes the failure rate fell to 1.63%. It was clear the changes were needed.

The changes required include:

• Changing the ServerHello version and record layer version post ServerHello to 0x0303
• Restoring missing fields from the ServerHello message.
• Merging the HelloRetryRequest into the ServerHello message.
• Ignoring ChangeCipherSpec messages in handshake.

It was first assumed that middleboxes would inspect ClientHello messages and pretty much ignore the responses like ServerHello and HelloRetryRequest messages. This didn’t work out in the real world. Therefore some of the ServerHello changes from TLS v1.2 had to be undone. All required changes are now available in wolfSSL.

Further optional compatibility changes are specified. This includes sending a ChangeCipherSpec before any encrypted data, thus the previous requirement to ignore these messages. wolfSSL has the ability to enable these with the use of the define: WOLFSSL_TLS13_MIDDLEBOX_COMPAT.

A more extensive test was performed by Mozilla after Draft 22 was released. The results (https://www.ietf.org/mail-archive/web/tls/current/msg25179.html) were:

• TLS v1.2 failure rate: 4.85% (3.25% US only)
• TLS v1.3 Draft 22: 5.02% (3.45% US only)
• TLS v1.3 Draft 22 Compat: 4.81% (3.24% US Only)

It is clear that the Draft 22 changes are working.

Draft 23 renumbered the KeyShare extension to allow for compatibility with CANON printers that were based on BSAFE and added a separate extension for negotiating certificate signatures.

wolfSSL by default supports Draft 23 but can be configured to support Draft 22 with: –enable-tls13-draft22. Also, for backwards compatibility for early adopters, Draft 18 support can be configured with: –enable-tls13-draft18.

If you have any questions or issues with wolfSSL’s TLS 1.3 implementation, please email us at facts@wolfssl.com, or our support team at support@wolfssl.com.

             

MySQL (#mysql) currently comes bundled with yaSSL to provide an option for SSL/TLS connections when using a database. A patch for securing MySQL with the wolfSSL embedded SSL/TLS library is available for MySQL version 8.0.0 here https://github.com/wolfSSL/mysql-patch.

Along with an increased level of security comes the potential to use progressive features offered by wolfSSL – such as TLS 1.3 and ChaCha20 / Poly1305 AEAD cipher suites (ex: ECDHE-RSA-CHACHA20-POLY1305). Another great feature is that wolfSSL cryptography is FIPS 140-2 validated! The change from yaSSL to wolfSSL will fit nicely into both Open Source and commercial applications, as it is dual licensed under both GPLv2 and standard commercial license terms.

For more information about the port, or to provide us feedback, contact us at facts@wolfssl.com!

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.

Job Description:

Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.  Experience with hardware-based cryptography is a plus.

Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

To apply or discuss, please send your resume and cover letter to facts@wolfssl.com.

We are working on adding MQTT v5.0 support to wolfMQTT.

Some of the new MQTT 5 features include:

• AUTH packet type to submit authentication method/data information after connect.
• CONNACK packets now include a reason code to better describe connect failures.
• DISCONNECT now supports server to client.
• Packets can include optional key/value properties.
• New data type for UTF-8 string pairs.
• No retry for QoS 1 and 2 packets (let assumed TCP handle retry).
• Passwords can be provided without a username

The new specification can be found here:
http://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html

Support for these new features will be release in the next few weeks as wolfMQTT v1.0.

We’re excited that wolfSSL embedded SSL/TLS library now includes support for TLS 1.3 and think that there are many advantages to using TLS 1.3 in applications, projects and devices.  Here are the top 5 advantages to using TLS 1.3 with wolfSSL:

1. More secure than older TLS protocol versions by eliminating risky crypto
2. Reduces latency through fewer roundtrips in the TLS handshake
3. The server can be stateless when resuming a session
4. We are the first and only commercial license supplier of TLS 1.3 library for embedded devices today
5. We are the only company to support its own TLS 1.3 stack

If you would like to talk in more detail about using TLS 1.3, contact us at facts@wolfssl.com!

We are excited to announce that wolfCrypt v4.0 is currently in process for CMVP validation for FIPS 140-2. We are adding more algorithms to our security boundary including ECDSA, ECDHE, AES-GCM, AES-CCM, SHA-3, and RSA-PSS. Also included is FIPS 186-4 compliant key generation for RSA and ECC. We will be able to offer TLSv1.3 with FIPS validated cryptography for embedded devices. For more information, please email fips@wolfssl.com.

wolfSSL has supported the ThreadX/NetX RTOS with the TLS protocol. Recently we added the ability to use DTLS with NetX. Out of the box, wolfSSL has the I/O callback functions for handling UDP packets for DTLS. As an extension to DTLS, wolfSSL also supports Multicast DTLS. If you would like to know more please contact our sales team via email, sales@wolfssl.com

We at wolfSSL are pleased to announce that now you can use wolfSSL directly from Docker!

In a few words, Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers are like virtual machines, but way more lighter as the container shares some resources with the hosting machine.

We created a collection of wolfSSL containers targeting the following OSs: Debian, Ubuntu, Alpine Linux, CentOS

There are 3 different flavors of containers we have created based on each OS, they are: lib, test and examples

wolfssl/wolfssl ubuntu-examples 9198e6d82596 127MB
wolfssl/wolfssl ubuntu-test     ba5ca8ca4359 351MB
wolfssl/wolfssl ubuntu-lib      125125eea7ab 126MB
ubuntu          latest          2d696327ab2e 122MB
wolfssl/wolfssl debian-examples cd066ee3b5db 106MB
wolfssl/wolfssl debian-test     5a3edb3a2a20 356MB
wolfssl/wolfssl debian-lib      3086ef0f07b6 105MB
debian          latest          72ef1cf971d1 100MB
wolfssl/wolfssl centos-examples 37687e96d5b9 222MB
wolfssl/wolfssl centos-test     359d4195ca53 392MB
wolfssl/wolfssl centos-lib      a8c6cafd6205 221MB
centos          latest          196e0ce0c9fb 197MB
wolfssl/wolfssl alpine-examples 490120f86d61 8.74MB
wolfssl/wolfssl alpine-test     52b698631bec 228MB
wolfssl/wolfssl alpine-lib      692a0c26cda6 7.97MB
alpine          latest          76da55c8019d 3.97MB

The -lib images contains only the wolfSSL binaries, while -examples also contains the test examples and -test also contains wolfSSL’s source code.

You can find further information on how to run wolfSSL examples on a docker container in our docker hub page: https://hub.docker.com/u/wolfssl/

And here is a quick example, server in the left tab and the client in the right tab:

wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.

Job Description:

Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.  Experience with hardware-based cryptography is a plus.

Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.

Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.

How To Apply

To apply or discuss, please send your resume and cover letter to facts@wolfssl.com.

wolfSSL now supports Open Whisper Systems Signal Protocol C Library!  This means that you can now develop Signal applications using wolfCrypt as the underlying cryptography provider.

For those unfamiliar with the Signal Protocol, it is described on their GitHub page as “A ratcheting forward secrecy protocol that works in synchronous and asynchronous messaging environments.”

wolfCrypt Signal Protocol Integration

By design, the Signal Protocol C Library does not depend on any SSL/TLS or cryptography library.  Instead, Signal allows the application to register a crypto provider at runtime.  We recently ported the wolfCrypt cryptography library into the “libsignal-protocol-c” test code and added a CMake configuration to build the libsignal-protocol-c test programs using cryptography from wolfSSL.

With this build option and wolfCrypt integration, Signal application developers can choose to use cryptography from wolfSSL instead of OpenSSL.  Thanks to wolfSSL’s small footprint size, low memory usage, and broad platform support, application developers can more easily use the Signal Protocol C Library on small resource-constrained platforms and embedded systems.

For more information on using wolfCrypt with Signal, contact us at facts@wolfssl.com!