RECENT BLOG NEWS

wolfSSL's wolfSSH library is a small footprint, fast, embedded SSH implementation. With recent additional support and adjustments, support for non-blocking connections has been added to the library! This allows for use of non-blocking connections with other features besides SSH, such as use with SFTP and SCP. This non-blocking support is supported by default and is easy to use. The default API can be called and the wolfSSH library internally handles all saving and restoring of states, returning WS_WANT_READ or WS_WANT_WRITE when calling wolfSSH_get_error() to signal if the API should be called again. The library is designed to be easy to use and quick to integrate into an application.

For more information about wolfSSH or using it in your project, please contact facts@wolfssl.com.

Spring is here, and along with it is the newest and shiniest release of the wolfSSL embedded SSL/TLS library!

As with every release, this release includes many feature additions, bug fixes, and improvements to the wolfSSL library. Additionally, this new version of the wolfSSL library includes support for the new FIPS 140-2 Certificate for wolfCrypt v4.0! More information on wolfSSL and FIPS can be found here: https://www.wolfssl.com/license/fips/.

The list below outlines the new feature additions that are included with the release of wolfSSL version 4.0.0:

• Support for wolfCrypt FIPS v4.0.0, certificate #3389
• FIPS Ready Initiative
• Added TLS server side secure renegotiation
• Added TLS Trusted CA extension
• Support for the Deos Safety Critical RTOS
• TLS handshake now supports using PKCS #11 for private keys
• PKCS #11 support of HMAC, AES-CBC and random seeding/generation
• Support for named FFDHE parameters in TLS 1.2 (RFC 7919)
• Added Espressif ESP32 WROOM support with hardware crypto acceleration. More data can be found here: https://www.wolfssl.com/docs/benchmarks/#espressif_esp32_wroom.
• Added Cypress WICED Studio support
• Added ARM CMSIS-RTOS v2 support
• Added port to the Zephyr Project
• Added Cortex-M support for Single Precision (SP) math
• Added wolfCrypt RSA non-blocking time support
• Added 16-bit compiler support using --enable-16bit option

Additionally, the wolfSSL blog will be posting more elaboration and details on the ports and support that have been added with this release in the furture. Stay tuned for more information!

The following list outlines the various fixes, updates, and general improvements that have been included with wolfSSL 4.0.0:

• Added new wrapper for snprintf for use with certain Visual Studio builds
• Added ECC_PUBLICKEY_TYPE to the supported PEM header types
• Added strict checking of the ECDSA signature DER encoding length
• Added ECDSA option to limit sig/algos in client_hello to key size with USE_ECDSA_KEYSZ_HASH_ALGO
• Compatibility fixes for secure renegotiation with Chrome
• Better size check for TLS record fragment reassembly
• Improvements to non-blocking and handshake message retry support for DTLS
• Improvements to OCSP with ECDSA signers
• OCSP fixes for memory management and initializations
• Fixes for EVP Cipher decryption padding checks
• Removal of null terminators on wolfSSL_X509_print substrings
• wolfSSL_sk_ASN1_OBJCET_pop function renamed to wolfSSL_sk_ASN1_OBJECT_pop
• Adjustment to include path in compatibility layer for evp.h and objects.h
• Fixes for decoding BER encoded PKCS7 contents
• Move the TLS PRF to wolfCrypt.
• Update to CMS KARI support
• Fixes and additions to the OpenSSL compatibility layer
• Xcode project file update
• Fixes for ATECC508A/ATECC608A
• Fixes issue with CA path length for self signed root CA's
• Fixes for Single Precision (SP) ASM when building sources directly
• Fixes for STM32 AES GCM
• Fixes for ECC sign with hardware to ensure the input is truncated
• Fixes for proper detection of PKCS7 buffer overflow case
• Fixes to handle degenerate PKCS 7 with BER encoding
• Fixes for TLS v1.3 handling of 6144 and 8192 bit keys
• Fixes for possible build issues with SafeRTOS
• Improved Arduino sketch example
• Improved crypto callback features
• Improved TLS benchmark tool

There was also a bug in the tls_bench.c example test application (unrelated to the crypto or TLS portions of the library) that was resolved in wolfSSL 4.0.0 - CVE-2019-6439.

To download and view the most recent version of wolfSSL, the wolfSSL GitHub repository can be cloned from here: https://github.com/wolfssl/wolfssl.git, and the most recent stable release can be downloaded from the wolfSSL download page here: https://www.wolfssl.com/download/.

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

Since earlier versions, wolfSSL's embedded SSL/TLS library has been included with MPLAB Harmony. MPLAB Harmony is a flexible, fully integrated embedded software development framework for 32-bit MCUs and MPUs. Recently, MPLAB Harmony version 3 was released, with wolfSSL packaged within! The new release of MPLAB Harmony features aspects from the latest version of wolfSSL, version 3.15.7. wolfSSL is included in such a way that the example applications, demos, and source code of the wolfSSL library can be easily integrated and executed with other MPLAB projects. Additionally, other software libraries and examples are also being included in this new release of MPLAB Harmony, such as CMSIS-FreeRTOS.

For more information on the new release of MPLAB Harmony v3, please visit Microchip's page here: https://www.microchip.com/mplab/mplab-harmony/mplab-harmony-v3.

For more information about wolfSSL, wolfSSL with MPLAB Harmony, or other general inquiries, please contact facts@wolfssl.com.

 

wolfSSL provides many different products for many different implementations of internet protocols, one of which is wolfMQTT. The wolfMQTT library is a client implementation of the MQTT written in C for embedded use, with support for SSL/TLS via the wolfSSL library, and also provides support for MQTT-Sensor Network (MQTT-SN). While wolfMQTT is based on the MQTT 3.1.1 specification, wolfMQTT also provides support for the MQTT v5.0 specification - which was recently approved and standardized by OASIS. This new standard comes with some changes, which are outlined below (from the MQTT v5.0 standard):

• Enhancements for scalability and large scale systems
• Improved error reporting
• Formalize common patterns including capability discovery and request response
• Extensibility mechanisms including user properties
• Performance improvements and support for small clients

For more information about wolfMQTT or its MQTT v5.0 support, please contact facts@wolfssl.com.

Reference
wolfMQTT GitHub Repository: https://github.com/wolfssl/wolfmqtt.git
wolfMQTT User Manual: https://www.wolfssl.com/docs/wolfmqtt-manual/
MQTT v5.0 specification: https://docs.oasis-open.org/mqtt/mqtt/v5.0/cos02/mqtt-v5.0-cos02.html#_Toc1477318

wolfSSL's embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:

TLS 1.3

This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences include:

• The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
• A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
• Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
• All handshake messages after the ServerHello are now encrypted.
• Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
• The handshake state machine has been restructured to be more consistent and remove superfluous messages.
• ECC is now in the base spec  and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
• Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
• TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
• Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

More information about the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/. Additionally, please contact facts@wolfssl.com for any questions.

Have you heard talk about SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 but never really knew the differences between the different versions? Secure Socket Layer (SSL) and Transport Security Layer (TLS) are both cryptographic protocols which provide secure communication over networks. These different versions are all in widespread use today in applications such as web browsing, e-mail, instant messaging and VoIP, and each is slightly different from the others.

wolfSSL supports all three of these ciphers to best suit your needs and requirements. Below you will find the major differences between the different protocol versions.

SSL 3.0
This protocol was released in 1996, but first began with the creation of SSL 1.0 developed by Netscape. Version 1.0 wasn`t released, and version 2.0 had a number of security flaws, thus leading to the release of SSL 3.0. Some major improvements of SSL 3.0 over SSL 2.0 are:
– Separation of the transport of data from the message layer
– Use of a full 128 bits of keying material even when using the Export cipher
– Ability of the client and server to send chains of certificates, thus allowing organizations to use certificate hierarchy which is more than two certificates deep.
– Implementing a generalized key exchange protocol, allowing Diffie-Hellman and Fortezza key exchanges as well as non-RSA certificates.
– Allowing for record compression and decompression
– Ability to fall back to SSL 2.0 when a 2.0 client is encountered

Netscape`s Original SSL 3.0 Draft: http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
Comparison of SSLv2 and SSLv3: http://stason.org/TULARC/security/ssl-talk/4-11-What-is-the-difference-between-SSL-2-0-and-3-0.html

TLS 1.0
This protocol was first defined in RFC 2246 in January of 1999. This was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don`t interoperate. Some of the major differences between SSL 3.0 and TLS 1.0 are:
– Key derivation functions are different
– MACs are different – SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC.
– The Finished messages are different
– TLS has more alerts
– TLS requires DSS/DH support

RFC 2246: http://tools.ietf.org/html/rfc2246

TLS 1.1
This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:
– The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
– Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
– IANA registries are defined for protocol parameters
– Premature closes no longer cause a session to be non-resumable.

RFC 4346: http://tools.ietf.org/html/rfc4346#section-1.1

TLS 1.2
This protocol was defined in RFC 5246 in August of 2008. Based on TLS 1.1, TLS 1.2 contains improved flexibility. The major differences include:
– The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
– The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash. Signed elements include a field explicitly specifying the hash algorithm used.
– There was substantial cleanup to the client`s and server`s ability to specify which hash and signature algorithms they will accept.
– Addition of support for authenticated encryption with additional data modes.
– TLS Extensions definition and AES Cipher Suites were merged in.
– Tighter checking of EncryptedPreMasterSecret version numbers.
– Many of the requirements were tightened
– Verify_data length depends on the cipher suite
– Description of Bleichenbacher/Dlima attack defenses cleaned up.

RFC 5246: http://tools.ietf.org/html/rfc5246

TLS 1.3
This protocol is currently being revised, and is in its 28th draft. The major differences from TLS 1.2 include:
– The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
– A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
– Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
– All handshake messages after the ServerHello are now encrypted.
– Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
– The handshake state machine has been restructured to be more consistent and remove superfluous messages.
– ECC is now in the base spec and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
– Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
– TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
– Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

RFC 8446: https://tools.ietf.org/html/rfc8446

Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS – Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL versus TLS – What`s the Difference? (http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html)
Cisco – SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)

As always, if you have any questions or would like to talk to the wolfSSL team about more information, please contact facts@wolfssl.com.

wolfSSL provides support on four levels, one of which is the 24x7 support level. This support level includes many key features not available on the others, such as an unlimited number of support incidents, around-the-clock support from dedicated members of the wolfSSL support team, and remains in effect for an entire year.

wolfSSL provides three other levels of paid support, which also include some of the same features provided by 24x7 support. More details on the wolfSSL support packages and levels can be viewed here: https://www.wolfssl.com/products/support-packages-options/

wolfSSL also provides support for the latest version of the TLS protocol, TLS 1.3! Read more about wolfSSL's implementation and the protocol itself here: https://www.wolfssl.com/docs/tls13/

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

wolfSSL is excited to announce support for Espressif ESP32 hardware acceleration to the wolfSSL embedded SSL/TLS library!

The ESP32-WROOM-32 is a powerful, generic Wi-Fi+BLE MCU module with high flexibility, and is easily interactable with the wolfSSL embedded SSL/TLS library. As wolfSSL is highly portable and the ESP32-WROOM-32 is highly flexible, if your application has any special features that interfere with the existing wolfSSL port, they are easily remedied.

The new wolfSSL ESP32-WROOM-32 port functionality was added into the existing ESP-IDF port, and the ESP32-WROOM-32 functionality can be enabled by either defining the "WOLFSSL_ESPIDF" and “WOLFSSL_ESPWROOM32” or “WOLFSSL_ESPWROOM32SE” options in the settings.h file (or user_settings.h alternatively, if WOLFSSL_USER_SETTINGS is defined). For more details about this new ESP32 support, please see the REAMDE.md placed in the “<wolfssl-root>/wolfcrypt/src/port/Espressif” directory of the wolfSSL source tree. Details about the ESP-IDF port can be found in the README.md file located in "<wolfssl-root>/IDE/Espressif/".

wolfSSL's support for the onboard hardware cryptography of the ESP32 and ATECC608A gives users code size reductions and performance advantages.  A full set of benchmarks and performance comparisons can be found on our ESP32-specific webpage, located here: https://www.wolfssl.com/docs/espressif/.

The wolfSSL master branch can be cloned from here: https://github.com/wolfSSL/wolfssl
The README about ESP-IDF porting can be found here: https://github.com/wolfSSL/wolfssl/blob/master/IDE/Espressif/ESP-IDF/README.md
The README about HW acceleration can be found here: https://github.com/wolfSSL/wolfssl/blob/master/wolfcrypt/src/port/Espressif/README.md
The README about 32SE can be found here: https://github.com/wolfSSL/wolfssl/blob/master/IDE/Espressif/ESP-IDF/README_32se.md

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

Resources:
ESP32-WROOM-32 Overview: https://www.espressif.com/en/products/hardware/esp-wroom-32/overview

wolfSSL embedded SSL/TLS support the latest Microchip ATECC508A and ATECC608A I2C cryptographic coprocessors. Not only is wolfSSL compatible with CryptoAuthLib, wolfSSL has also been tested on both the 508A and the 608A.

Prerequisites:

• Requires the Microchip CryptoAuthLib (https://github.com/MicrochipTech/cryptoauthlib.git)

Examples:

• wolfSSL uses PK (Public Key) callbacks for the TLS crypto operations
• wolfCrypt uses the WOLFSSL_ATECC508A macro to enable native wc_ecc_* API support
• wolfCrypt also uses the WOLFSSL_

The README.md and reference PK callbacks can be found here: https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/atmel

Additional demos for wolfSSL TLS Client/Server and wolfCrypt test/benchmarks can be found:

https://www.wolfssl.com/download/downloadMoreForm.php
https://github.com/dgarske/atmel

Preprocessor Macros:

• WOLFSSL_ATECC508A
• WOLFSSL_ATECC_PKCB
• WOLFSSL_ATMEL

PK Callbacks:

wolfSSL’s TLS layer PK callbacks expose API’s to set ECC callbacks. These are enabled with: #define HAVE_PK_CALLBACKS or ./configure --enable-pkcallbacks.

Reference API’s:

• atcatls_create_key_cb
• atcatls_verify_signature_cb
• atcatls_sign_certificate_cb
• atcatls_create_pms_cb

For more questions please email us at facts@wolfssl.com.