RECENT BLOG NEWS

If you are looking for an SSL/TLS library to provide security in connected ARM environments, wolfSSL is by far the best choice. wolfSSL is an ARM partner, and our code has been optimized for ARM environments. Public key operations in CyaSSL (wolfSSL) have optimized assembly code that gives wolfSSL faster RSA, Diffie-Hellman, and DSA times.

Optimized assembly code for public key operations can be found in asm.c and are easy to use, simply run ./configure –enable-fastmath and for stack usage reduction we also recommend using TFM_TIMIN_RESISTANT.

For any question regarding wolfSSL in ARM environments please contact us at facts@wolfssl.com.

Below is a link to wolfSSL’s SSL/TLS tutorial video on setting up a basic client and server with the CyaSSL lightweight, embedded SSL/TLS library. This video provides a detailed step-by-step set of instructions, including code, for incorporating CyaSSL into an application. The tutorial walks through Chapter 11 of the CyaSSL manual.

SSL/TLS Tutorial with CyaSSL Lightweight SSL:
https://www.youtube.com/watch?v=-Smp3X1eWNQ

For more information please contact us at facts@wolfssl.com or go to www.wolfssl.com. Instructions for building CyaSSL may be found in Chapter 2 of the CyaSSL Manual.

Some TLS implementations are vulnerable to the October POODLE attack that at the time was thought to be limited to SSLv3 only: https://www.imperialviolet.org/2014/12/08/poodleagain.html .  These implementations are incorrectly using a SSLV3 decoding function while in TLS mode.  wolfSSL is not susceptible, it correctly uses TLS decoding while in TLS mode.  We would like to reiterate Adam Langley’s advice to use TLS 1.2 with an AEAD cipher suite whenever possible.  wolfSSL supports TLS 1.2 and has 3 cipher suite types supporting AEAD; AES-GCM, AES-CCM, and CHACHA20-POLY1305.  29 different AEAD cipher suites are available with TLS 1.2 in wolfSSL.  Please contact us at facts@wolfssl.com if you have any questions or comments.

CyaSSL version 3.3.0 offers:

• Secure countermeasures for Handshake message duplicates, CHANGE CIPHER without FINISHED, and fast forward attempts added to our source code.  Thanks to Karthikeyan Bhargavan from the Prosecco team at INRIA Paris-Rocquencourt for the report.  This is an important fix and all users should update!
• Complete testing for FIPS 140-2 version submitted to NIST.  FIPS 140-2 source code now available.
• Removes SSLv2 Client Hello processing for enhanced security, can be enabled with OLD_HELLO_ALLOWED
• Protocol level control:  User can now control TLS protocol down-cycling to a minimum downgrade version with CyaSSL_SetMinVersion().  For example, you could reject handshakes at a protocol level less than TLS 1.1.
• Small stack improvements at TLS/SSL layer, to benefit environments with limited available stack.
• TLS Master Secret generation and Key Expansion are now exposed at the API level
• Adds client side Secure Renegotiation, * not recommended, ever! *
• Client side session ticket support.  This feature is not fully tested with Secure Renegotiation, so don’t use Secure Renegotiation.
• Allows up to 4096-bit DHE at TLS Key Exchange layer
• Handles non standard SessionID sizes in Hello Messages
• PicoTCP Support added
• TLS Sniffer now supports SNI Virtual Hosts
• TLS Sniffer now handles non HTTPS protocols using STARTTLS
• TLS Sniffer can now parse records with multiple messages
• TI-RTOS updates or enhances support
• Fix for ColdFire optimized fp_digit read only in explicit 32bit case
• Added ADH Cipher Suite ADH-AES128-SHA for EAP-FAST

Stay up to date with what is happening with wolfSSL, you can follow our blog at http://www.wolfssl.com/yaSSL/Blog/Blog.html

If you have any questions please feel free to contact us anytime at facts@wolfssl.com or (425)245-8247.
We look forward to hearing from you!

Thank You!
wolfSSL

INSTEON is leading the way in the field of home automation and control technology with a line of products that include a wide range of smart home devices such as lighting, motion detectors, and security systems. All INSTEON products can be centrally accessed through the Hub, a product that has the ability to connect the smart home even when the network is down.

While researching the best SSL/TLS library for securing the Hub, INSTEON found wolfSSL’s CyaSSL as the optimal solution. With its portable and lightweight design, CyaSSL was seamlessly integrated into INSTEON’s Hub, providing INSTEON users with a safe and secure network to manage all of their smart home devices.

To learn more about INSTEON and their wide range of devices, feel free to visit their website.  The INSTEON/wolfSSL case study can be viewed on our Case Studies page.

For questions regarding the use of wolfSSL products in your embedded or IoT devices, contact us at facts@wolfssl.com.

The next release of CyaSSL will have official support for the PicoTCP TCP/IP stack. wolfSSL has been working closely with the developers at TASS to add out-of-the-box support for this new, lightweight, and dual-licensed TCP/IP stack – making it easier to secure Internet of Things devices running on top of PicoTCP.

For those not familiar with PicoTCP, it is “a TCP/IP stack developed from the ground up for embedded devices, by embedded software engineers. Resource usage, modularity and portability to different hardware platforms and embedded operating systems are key.” Like CyaSSL, PicoTCP is open source and dual licensed under both the GPLv2 and a commercial license.

TASS has put together a helpful demo application using both CyaSSL and PicoTCP, with a walkthrough documented here:
http://www.picotcp.com/picotcp-and-cyassl-integration

When compiling CyaSSL for use with PicoTCP, users will need to define CYASSL_PICOTCP, and optionally CYASSL_PICOTCP_DEMO when compiling for use with the example demo application listed above.

If you are interested in using CyaSSL with PicoTCP, or have any questions, please contact us at facts@wolfssl.com.

PicoTCP: http://www.picotcp.com/
TASS Belgium (acquired by Altran): https://www.altran.com/nl/en/

Hi! We’ve been telegraphing our plans to drop support for SSL 3.0 for the last year. With the emergence of the POODLE breach, we’ve decided to accelerate our plan. Over the coming weeks and months, we’ll be doing the following:

1. Disabling SSL 3.0 by default at runtime.

2. Disabling our SSL 3.0 code by default at compile time.

3. Eliminating all SSL 3.0 code from our code base, and using TLS 1.0 as the base.

If you have comments or questions, then feel free to contact us at facts@wolfssl.com or call us up at +1 425 245 8247.

Team wolfSSL

SSL, the predecessor to TLS, reached version 3.0 before changing names to TLS. TLS versions currently defined include TLS 1.0, 1.1, and 1.2, with the 1.3 specification still being worked out.

“Padding Oracle On Downgraded Legacy Encryption” Bug (POODLE) was disclosed on October 14th, 2014 and allows an attacker to read information encrypted with SSL 3.0 in plain text using a man-in-the-middle attack. Here at wolfSSL we highly encourage our users to avoid using SSL 3.0 as an attacker can force a connection to use SSL 3.0 if it is available to both participants in the connection, thus allowing the attacker to exploit this bug.

POODLE effects any clients communicating with SSL 3.0. This is a flaw with the protocol design and not an implementation error. Therefore EVERY software application that uses SSL 3.0 is susceptible.

CyaSSL supports industry standards up to the current TLS 1.2 and as such is not vulnerable to the POODLE bug as long as our clients are using a version of TLS higher than SSL 3.0. It is highly recommended that TLS1.2 is used whenever possible.

References
http://www.entrust.com/poodle-kill-ssl-3-0/

Implementation of curve25519 is to the point where it is going through a testing cycle. We are looking for interested beta testers and cryptography enthusiasts who wish to test out just how fast it can be.

If interested in getting the source code for the curve25519 implementation, contact us at facts@wolfssl.com.

Secure Renegotiation will allow for a server to differentiate between an initial connection and a renegotiation, protecting against “man-in-the-middle” attacks during renegotiations.

“Secure Socket Layer (SSL) and Transport Layer Security (TLS)
renegotiation are vulnerable to an attack in which the attacker forms
a TLS connection with the target server, injects content of his
choice, and then splices in a new TLS connection from a client. The
server treats the client`s initial TLS handshake as a renegotiation
and thus believes that the initial data transmitted by the attacker
is from the same entity as the subsequent client data. This
specification defines a TLS extension to cryptographically tie
renegotiations to the TLS connections they are being performed over,
thus preventing this attack.” -Abstract RFC-5746

– We will have an alpha release available for testing in November or December. Interested parties should contact us at facts@wolfssl.com

– Although we`re adding Secure Renegotiation to wolfSSL, we discourage its use when not a strict requirement.

-Initially wolfSSL did not support Renegotiation as it was considered an insecure feature. As such there was no need to support Secure Renegotiation until there was a customer demand for it.

-We make it a priority to ensure our clients have all the necessary tools at their disposal. Therefore we are adding support for Secure Renegotiation for those users and customers where it is a strict requirement.

References
Internet Engineering Task Force, RFC-5746