RECENT BLOG NEWS

Researchers from two German universities have found that a large number of Android applications available today in the Google Play store have vulnerabilities related to SSL usage which may open the door for malicious man-in-the-middle attacks. You can find several blog posts explaining the vulnerabilities including one from Network World and the H Online.

The researchers explain several of the mis-use cases that can arise in these Android apps in their paper, linked below. Listed from the paper, these include:

“Trusting all Certificates. The TrustManager interface can be implemented to trust all certificates, irrespective of who signed them or even for what subject they were issued.

Allowing all Hostnames. It is possible to forgo checks of whether the certificate was issued for this address or not, i. e., when accessing the server example.com, a certificate issued for some-other-domain.com is accepted.

Trusting many CAs. This is not necessarily a flaw, but Android 4.0 trusts 134 CA root certificates per default. Due to the attacks on several CAs in 2011, the problem of the large number of trusted CAs is actively debated.

Mixed-Mode/No SSL. App developers are free to mix secure and insecure connections in the same app or not use SSL at all. This is not directly an SSL issue, but it is relevant to mention that there are no outward signs and no possibility for a common app user to check whether a secure connection is being used. This opens the door for attacks such as SSL stripping or tools like Firesheep.”

To read the full paper, take a look here. The wolfSSL embedded SSL library runs on Android and can be used in Android NDK-based applications for SSL support. If you need guidance on how to correctly use wolfSSL in your project or application, email us at info@yassl.com for more information.

Research Paper: Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security
Network World: Some Android apps have serious SSL vulnerabilities, researchers say

On October 12, NIST announced Keccak as the winner of its Secure Hash Algorithm (SHA-3) competition.

Keccak is designed to permute the data in a different manner than MD5, SHA-1, and SHA-2, making it immune to many of the attacks on those hashes. It promises roughly 13 cycles per byte to process the hash. The hash is limited to using bitwise XOR, AND, NOT, and rotations. It will need up to 1600 bytes of RAM for the hash state, but no lookup tables. It provides arbitrary sized output. Keccak can also perform keyed hashing, by setting the initial state by priming the hash with the key. The algorithm is simple and small, perfect for embedded systems.

If you would be interested in talking about Keccak, SHA-3, and wolfSSL embedded SSL, send an email to info@yassl.com.

1. http://www.nist.gov/itl/csd/sha-100212.cfm
2. http://keccak.noekeon.org/

Do you currently use the Yocto Project or OpenEmbedded? We would like to announce the availability of the “meta-yassl” layer for both Yocto and OpenEmbedded. This layer adds support for the lightweight wolfSSL embedded SSL library to these projects and can be easily added to your existing Yocto or OpenEmbedded setup. The layer can be found on GitHub at the following URL:

https://github.com/cconlon/meta-yassl

If you are not familiar with the Yocto Project, it is an “open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture.” You can learn more about Yocto at www.yoctoproject.org or OpenEmbedded at www.openembedded.org.

As a reminder, wolfSSL is open source and dual licensed under both the GPLv2 as well as a standard commercial license. This means you are free to prototype with, test with, or use wolfSSL free of charge under the terms of the GPLv2. If your project will need a commercial license or you would like commercial support direct from yaSSL, please contact us and we’ll be happy to give you more details.

If you have any questions about the new meta-yassl layer, the wolfSSL embedded SSL library, or how we can help you integrate SSL into your project, please contact us at info@yassl.com.

yaSSL and Intel have jointly published a white paper describing how Intel’s AES-NI can be used with the wolfSSL embedded SSL library. This paper provides a brief overview of the Intel AES-NI instructions and demonstrates the performance gains realized when Intel AES-NI is used in place of a more traditional software-only based AES implementation. The wolfSSL embedded SSL library developed by yaSSL, is used as a test bed in the white paper to perform the comparison as it can be built with either traditional AES or AES-NI support at compile time. As a secondary goal to demonstrating Intel AES-NI performance, this paper explains how to determine if a pre-built SSL library (static or shared) offers built-in support for the Intel Advanced Encryption Standard New Instructions.

You can download the white paper directly from the yaSSL website at the following location. If you have any questions about using wolfSSL on Intel hardware, please contact us at info@yassl.com.

wolfSSL AES-NI White Paper: yaSSL White Papers (http://yassl.com/yaSSL/cyassl-embedded-ssl-white-papers.html)

You may have noticed that with our most recent release of the wolfSSL embedded SSL library (2.3.0), we have made our example client and server applications more flexible and easier to use. These updated applications – client (./examples/client/client) and server (./examples/server/server) – now offer a variety of command line options to adjust things ranging from SSL certificates to protocol version selection.

Looking at the example client application, if you run the app with the “–help” option, you will see a list of supported options:

./examples/client/client –help
client 2.3.1 NOTE: All files relative to wolfSSL home dir
-? Help, print this usage
-h Host to connect to, default 127.0.0.1
-p Port to connect on, default 11111
-v SSL version [0-3], SSLv3(0) – TLS1.2(3)), default 3
-l Cipher list
-c Certificate file, default ./certs/client-cert.pem
-k Key file, default ./certs/client-key.pem
-A Certificate Authority file, default ./certs/ca-cert.pem
-b Benchmark connections and print stats
-s Use pre Shared keys
-d Disable peer checks
-g Send server HTTP GET
-u Use UDP DTLS
-m Match domain name in cert

Likewise, looking at the server, you can see a variety of command line options available as well:

./examples/server/server –help
server 2.3.1 NOTE: All files relative to wolfSSL home dir
-? Help, print this usage
-p Port to listen on, default 11111
-v SSL version [0-3], SSLv3(0) – TLS1.2(3)), default 3
-l Cipher list
-c Certificate file, default ./certs/server-cert.pem
-k Key file, default ./certs/server-key.pem
-A Certificate Authority file, default ./certs/client-cert.pem
-d Disable client cert check
-b Bind to any interface instead of localhost only
-s Use pre Shared keys
-u Use UDP DTLS

We hope this will make testing connections and wolfSSL builds much easier and less time consuming. If you have any suggestions for future improvement, please let us know at info@yassl.com.

The CRIME attack has been in the news recently, and some of our users have been asking about it.  The short version of responding to the attack is simple:  disable TLS compression.  In wolfSSL, compression is disabled by default.  The Tor project has posted an excellent explanation of the attack in their blog.  For more details, see:  https://blog.torproject.org/blog/some-thoughts-crime-attack.  

If you have questions on this attack in relation to wolfSSL, please contact us at info@yassl.com.

Hi!  To our users concerned about the following security advisory:  http://www.securelist.com/en/advisories/50605 (as of 26 March 2018 at 9:28am MDT, this link no longer works and has no alternative), it is a vulnerability related specifically to SSL 3.0 and TLS 1.0.  When using CyaSSL, you can avoid this vulnerability using one of several methods, including:

1. 1. Using a higher level of the SSL/TLS protocol – either TLS 1.1 or TLS 1.2

2. 2. Using TLS 1.0 or SSL 3.0 with a stream cipher. CyaSSL supports several, including RC4, HC-128, and RABBIT.

3.  If you must use SSL 3.0 or TLS 1.0 with a block cipher, split the first SSL write at the application level into fragments (as modern browsers do).

If you have further concerns or questions, please contact us at info@yassl.com.

If you are a user of the popular MacPorts project on OS X, you may be happy to hear that the wolfSSL embedded SSL library is now available as a MacPorts package. If you are not familiar with the MacPorts Project, a brief summary from their website does an excellent job of explaining the project. At the time this post was written, there were 15,657 ports in the MacPorts tree.

As stated on their homepage, “The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system. To that end we provide the command-line driven MacPorts software package under a BSD License, and through it easy access to thousands of ports that greatly simplify the task of compiling and installing open-source software on your Mac.

We provide a single software tree that attempts to track the latest release of every software title (port) we distribute, without splitting them into “stable” Vs. “unstable” branches, targeting mainly the current Mac OS X release (10.8, A.K.A. Mountain Lion) and the immediately previous two (10.7, A.K.A. Lion and 10.6, A.K.A. Snow Leopard).”

To install the wolfSSL MacPorts package on OS X, there are only a few simple steps required:

1. Download and install MacPorts (http://www.macports.org/install.php)
2. From the OS X terminal, run the command, “sudo port install cyassl”. This will install wolfSSL into the /opt/local directory.

To learn more about MacPorts, please visit their website at www.macports.com.

As you may know, CTaoCrypt is the underlying cryptography library used by the wolfSSL embedded SSL library. We’ve had several users choose to use CTaoCrypt’s crypto algorithms because they are easy to isolate and use independently of the library itself. For example, if you need to use MD5 in your own code but don’t want to write it yourself, you could extract CTaoCrypt’s MD5 implementation and use it directly in your code.

Most crypto algorithms in CTaoCrypt are contained within a source file and header file. For MD5, the relevant code would be in ./cyassl/ctaocrypt/md5.h and ./ctaocrypt/src/md5.c. Other algorithms follow the same directory and source file pattern.

If you have any questions about using CTaoCrypt’s algorithms separately, please let us know at info@yassl.com. As always, feel free to download the GPLv2-licensed source code for wolfSSL/CTaoCrypt directly from our download page and try it out for yourself.

The third release of the yaSSL Embedded Web Server is now available for download!  Changes in this release include bug fixes, updated wolfSSL support, iOS (Apple TV) build support, better Windows build support, CGI and SSI extension pattern matching and more.

The yaSSL Embedded Web Server is focused on being small, fast, and embeddable.  Features include CGI, SSI, IP restrictions, access and error log support, and SSL among others.  The wolfSSL embedded SSL library can be used to easily secure ports with SSL/TLS up to TLS 1.2, giving you a secure connection while maintaining small size and fast speed.  

If you have any questions, or would like to learn more about the yaSSL Embedded Web Server and how it can help your project, please contact info@yassl.com.