RECENT BLOG NEWS

Version 1.1.0 of wolfSSL JNI is now available for download. wolfSSL JNI provides Java applications with a convenient Java API to the widely-used CyaSSL lightweight SSL/TLS library, including support for TLS 1.2 and DTLS 1.2.

This release contains bug fixes and features including:

– Updated support for CyaSSL, tested against CyaSSL 2.9.4
– Updated example certificates and CRLs for use with the included example client and server applications
– Test framework modification which now expects the user to have JUnit JARs installed on the development platform
– Updated unit tests and conversion from JUnit3 to JUnit4
– Android NDK support
– CRL monitor is now optional in server mode

Additional information regarding using wolfSSL JNI with Android NDK-based applications will follow in a separate post. wolfSSL JNI 1.1.0 can be downloaded from the wolfSSL download page and the wolfSSL JNI Manual can be found here.

The OpenBSD team is refactoring OpenSSL, which is admirable work.  You can see their progress at http://opensslrampage.org.

If you read the OpenSSL Rampage blog, you can see that they have their work cut out for them.  The OpenSSL code base is very old, and has had literally hundreds of unknown hands making changes over its 20+ year lifespan.  

The OpenSSL Heartbleed bug has been motivating for a lot of developers, which is probably Heartbleed`s only positive side effect.  As the creators of wolfSSL, a modern clean room implementation of SSL/TLS, we`ve been hearing from a lot of OpenSSL consumers that want to make a change.  They`ve had enough of working with a code base held together with rubber bands and twine.  Here`s why we think OpenSSL users should consider a switch to wolfSSL instead of patching, re-factoring, and hoping:

1.  wolfSSL is clean room developed, which means that we don`t use any OpenSSL code in our implementation of SSL/TLS.  We can point to every developer that has touched a line of our code base.  

2.  Switching from OpenSSL to wolfSSL can be relatively easy.  We usually estimate 1-4 weeks for a project where we rip and replace OpenSSL for wolfSSL.  

3.  If you`re making the switch, we`ll support you, whether you`re an open source project or a commercial user.  

4.  Our code is newer, more modern, and clean.  You should be able to understand the security code plugged into your application, and we think ours is a quick read for competent C/C++ programmers.

5.  We support an OpenSSL compatibility layer which supports the 400 or so most used functions in OpenSSL.  We`ll help you if you need extensions to the layer.

If you have questions, thoughts, or comments to share with us, please email us at facts@wolfssl.com, or call us at +1 425 245 8247.

If you are using or thinking about using the wolfSSL lightweight SSL/TLS library in your application or project, it’s oftentimes helpful to get a general overview of some of the terms and types which are used in a simple wolfSSL connection. Below we have included a general summary of these types.

1) socket: wolfSSL uses the type SOCKET_T to allow different TCP stacks to be used.

2) SSL Context:  wolfSSL uses the type CYASSL_CTX*.  This is either a client context or a server context.  Multiple SSL connections can be created from a single CYASSL_CTX*.  The context holds CA certificates, keys, and options for the connections that will be created from it.

3) SSL Connection:  wolfSSL uses the type CYASSL* to represent a single SSL connection.  This object is created from a parent CYASSL_CTX*.  It may contain a SOCKET_T if the underlying I/O is socket based, but that is not a requirement. With wolfSSL’s I/O callbacks a memory buffer, file, or event handler may be used instead.

1) SSL Session:  wolfSSL uses the type CYASSL_SESSION*.  Each time a full SSL handshake is done on a CYASSL* Connection object a new CYASSL_SESSION* is created.  A single CYASSL_SESSION* can later be used to do session resumption on multiple different CYASSL* connections.

For example, let`s say a browser has 3 tabs open to a simple secure site.  The browser would need:

1 CYASSL_CTX* client context with CA certificates loaded.

3 SOCKET_T sockets, 1 for each tab.

3 CYASSL* connections, one for each tab.  Each connection owns one of the 3 unique SOCKET_T but was created from the same CYASSL_CTX*.

1 CYASSL_SESSION* was created from the first tab.  The 2nd and 3rd tab would use the initial CYASSL_SESSION* to do session resumption with their respective CYASSL* connections.

Code wise, to retrieve a session the application would just call wolfSSL_get_session() before ending the connection with wolfSSL_shutdown().

CYASSL_SESSION* mySession = wolfSSL_get_session(ssl_conn1);

To later use that session on a new CYASSL connection (ssl_conn2), do:

wolfSSL_set_session(ssl_conn2, mySession);

before calling wolfSSL_connect().  Connection 2 will attempt session resumption.

For more detailed information, the wolfSSL API reference discusses each function in more detail: http://www.yassl.com/yaSSL/Docs-cyassl-manual-17-cyassl-api-reference.html

The wolfSSL example client (examples/client/client.c in the general wolfSSL download) does session resumption if the user passes -r to the command line.  If you search for get_session and set_session you should see right where it`s used.

Dark Reading has a nice overview article covering IoT security issues.  See:  
http://www.darkreading.com/vulnerabilities—threats/thingularity-triggers-security-warnings/d/d-id/1141587

Issue #1 (Memory  Corruption)

CVE-ID:  CVE-2014-2896
Product: CyaSSL
Vendor: wolfSSL Inc.
Affected Versions: CyaSSL 2.9.0 and previous versions
Vulnerability Type:  Improper Input Validation (CWE-20)

Description: The TLS and DTLS implementations in wolfSSL CyaSSL before 2.9.4 lack a buffer length check in DoAlert(), possibly allowing an attacker to set the read index by up to 2 bytes past the length of the input buffer. This could result in memory corruption or a possible out-of-bounds read.

Thanks to Ivan Fratric of the Google Security Team for discovering this  bug.

Issue #2 (Out of bounds read)

CVE-ID: CVE-2014-2897
Product: CyaSSL
Vendor: wolfSSL Inc.
Affected Versions: CyaSSL 2.5.0 – CyaSSL 2.9.0
Vulnerability Type: Cryptographic Issues  (CWE-310)

Description: The SSL version 3 HMAC calculation does not check the padding length for a verify failure because many implementations get this wrong. But the length should still be checked to prevent an out-of-bounds read.

Thanks to Ivan Fratric of the Google Security Team for discovering and reporting this bug.

Issue #3 (Dangerous Default Behavior, out of bounds read)

CVE-ID: CVE-2014-2898
Product: CyaSSL
Vendor: wolfSSL Inc.
Affected Versions: CyaSSL 2.9.0 and previous versions
Vulnerability Type: Unchecked Error Condition (CWE-391)

Description: A user who repeatedly calls CyaSSL_read() without checking the return code can cause an out-of-bound memory access in an error case such as MAC verification failure.

Thanks to Ivan Fratric of the Google Security Team for discovering and reporting this bug.

Issue #4 (NULL pointer dereference)

CVE-ID: CVE-2014-2899
Product: CyaSSL
Vendor: wolfSSL Inc.
Affected Versions: CyaSSL 2.9.0 and previous versions
Vulnerability Type: Improper Input Validation (CWE-20)

Description: A user requesting the peer certificate in a certificate parsing failure case can cause a NULL-pointer dereference. Likewise, if an SSL client receives a client_key_exchange message a NULL-pointer dereference happens if the client does not have the peer’s ephemeral key.

Thanks to Ivan Fratric of the Google Security Team for discovering and reporting this bug.

Issue #5 (Unknown Critical Certificate Extension Allowed)

CVE-ID: CVE-2014-2900
Product: CyaSSL
Vendor: wolfSSL Inc.
Affected Versions: CyaSSL 2.9.0 and previous versions
Vulnerability Type: Improper Input Validation (CWE-20)

Description: Certificate validation must fail if unknown critical extensions are present in the certificate. CyaSSL previously accepted certificates with unknown critical extensions by default.

Thanks to Suman Jana and the security researchers at UT Austin and UC Davis for discovering and reporting this bug.

Release 2.9.4 includes important Security Fixes for issues found by Ivan Fratric of the Google Security Team and Suman Jana with security researchers at UT Austin and UC Davis.  CVE details to be posted today for issues with memory corruption, null pointer deference, out of bound read, and unknown certificate extensions.  All users should upgrade immediately.

This release also includes sniffer fixes for corrupted Jumbo Frames, ARM thumb mode assembly fixes, XCode 5.1 support, PIC32 MZ hardware support, a sample I/O pool, and FIPS mode for algorithms including AES, 3DES, SHA-1, SHA-2, HMAC, and RSA.

A recently-discovered bug in OpenSSL’s implementation of the TLS Heartbeat Extension makes it possible for malicious attackers to potentially recover the private keys and sensitive data that should normally be secured by SSL/TLS. The vulnerability has been recorded as CVE-2014-0160.

The purpose of this note is not to gloat over a competing projects problems, as some others have done, but rather to inform our user base.  The OpenSSL team and their supporters have done a good job on getting the bug fixed as well as informing their users.  We want to be the first to note that secure coding is not for the faint of heart, because it is a specialized expertise.  Building cryptography and the protocols on top of it is a difficult expertise to practice.

We want to assure our users and customers that CyaSSL and wolfSSL products are NOT affected by the Heartbleed bug in any way. We are a clean room implementation of SSL/TLS, and did not employ any of OpenSSL`s code base, which many others have done.  We should also note that the bug is not a protocol level bug that effects all SSL/TLS implementations. This was a bug specific to OpenSSL’s implementation of the TLS Heartbeat Extension. This bug existed in OpenSSL for over two years, with vulnerable versions including OpenSSL 1.0.1 – 1.0.1f (inclusive).

Interested parties can learn more about this bug in OpenSSL at the following links:

http://heartbleed.com/
https://www.openssl.org/news/secadv_20140407.txt
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

For additional information or questions about CyaSSL, please contact us at facts@wolfssl.com.

If you missed our recent presentation at FOSDEM, we just put our slide deck up online at the following URL:

https://speakerdeck.com/wolfssl/wolfssl-year-in-review

wolfSSL made significant progress in 2013 towards bringing the community a more usable, feature-rich, and better supported library for use in an ever-growing range of platforms and environments. These slides (and talk) provides an overview of technical progress in the last year (2013) and news on the current state of wolfSSL. Details on what`s new include the addition of new crypto ciphers and algorithms, better hardware cryptography support, more flexible abstraction layers, a JNI wrapper, new platform support, and better development tool integration.

As always, if you have any questions or comments, we welcome them at facts@wolfssl.com.

The new release of wolfSSL, v2.9.0, is now ready to download from our website. New features include:

Platforms:
– Freescale Kinetis
* RNGB support (K53 Sub-Family Reference Manual, Chapter 33)
* mmCAU support (ColdFire/ColdFire+ CAU and Kinetis mmCAU Software Library User Guide)

– Microchip
* MPLAB Harmony support

TLS Extensions:
– Supported Curves
– Secure Renegotiation
– Truncated HMAC

Public-Key Cryptography Standards:
– PKCS #7 Enveloped data and signed data
– PKCS #10 Certificate Signing Request generation

OCSP: (The new CRL):
– API change to integrate into Certificate Manager
– IPv4/IPv6 agnostic
– example client/server support
– OCSP nonces are optional

DTLS:
– Sliding window (Anti-replay)

ECC:
– Encrypt/Decrypt primitives
– Certificate generation

Others:
– GMAC hashing
– Additional X.509 inspection functions

Please see the README and our on-line documentation for more information or feel free to contact us.

We are back to talk about TLS extensions again. Today we present the addition of Supported Elliptic Curves on wolfSSL!

RFC 4492 introduces five new ECC-based key exchange algorithms for TLS: ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA and ECDH_anon. However, it may be desirable in constrained environments to only support a limited number of curves. When a client uses this extension, servers that understands it MUST NOT negotiate the use of an ECC cipher suite unless they can complete the handshake while respecting the choice of curves specified by the client. This eliminates the possibility that a negotiated ECC handshake will be subsequently aborted due to a client’s inability to deal with the server’s ECC key.

To enable the usage of Supported Elliptic Curves in wolfSSL you can simply do:

./configure –enable-supportedcurves

Using Supported Elliptic Curves on the client side requires additional function calls, which should be one of the following functions:

wolfSSL_CTX_UseSupportedCurve();
wolfSSL_UseSupportedCurve();

wolfSSL_CTX_UseSupportedCurve() is most recommended when the client would like to enable Supported Curves for all sessions. Setting the Supported Elliptic Curves extension at context level will enable it in all SSL objects created from that same context from the moment of the call forward.

wolfSSL_UseSupportedCurve() will enable it for one SSL object only, so it`s recommended to use this function when there is no need for Supported Elliptic Curves on all sessions.

These functions can be called more than once to indicate the support of multiple curves.

On the server side no call is required. The server will automatically attend to the client`s request selecting ECC cipher suites only if the supported curves are allowed.

All TLS extensions can also be enabled with:

./configure –enable-tlsx

If you have any questions about using TLS Extensions with wolfSSL please let us know at facts@wolfssl.com.