RECENT BLOG NEWS

We are often asked about how we test wolfSSL.  At this point, we believe we have testing that is quite robust, but we acknowledge that there is no such thing as perfect testing.  With that knowledge in mind, we have the goal of incrementally improving and automating our testing rigs over time.  Our overriding goal in testing is to have the most advanced and robust and ever improving testing that we can, subject to our resources.

We used to think of our testing plans in terms of a hierarchy, but we`ve improved on that thinking over time.  We currently represent our testing as a series of concentric universes, with each successively larger universe being vastly larger and more complex than the smaller one inside of it.  We`ll post some pictures in upcoming blog posts.  For now, here`s a rough representation of our testing universes in order of sequence:  

1.  Build options:  We have an extremely large number of build option combinations.  So our most basic test universe is to build successfully with every possible combination of options.

2.  API testing:  We test every available call in a particular build.

3.  Connection testing and data passing variables:  We start with simple connection tests with limited data transmitted and then gradually dial up complexity.

4.  Interop:  We test for interoperability with the other open source TLS implementations, including OpenSSL and GnuTLS.

5.  We then connect to unknown servers in the real world.

6.  We then build with a series of `real` applications, like cURL, wget, pppd, etc.  For some of our customers with top level support, we build the new release with their application.

7.  Finally, we engage in another ever expanding universe of benchmark testing, where we look at sizing, transmission rates, connection speeds, etc.  More to come on that topic, as it is quite popular!

Much of our effort is automated by Jenkins (hat tip to that project!).  Thanks for listening.  If you have specific questions about how we test, please contact us at facts@wolfssl.com.

Many of our customers use the wolfSSL lightweight SSL/TLS package in M2M applications where usage is charged based on data transfer.  As such, it becomes important to minimize data transfer rates when running SSL.  Here are a few thoughts on how wolfSSL M2M users can minimize data packet overhead when implementing our embedded SSL:

1) Use a stream cipher like RC4, HC-128, or RABBIT.  Stream ciphers don`t require padding, this will save at least half the cipher`s block size per message.

2) Use session resumption as much as possible.  TLS session resumption uses less round trips and about 1/3 of the data compared to a full handshake, depending on certificate sizes and the certificate chain length mainly.  wolfSSL now has a built-in client session cache so using session resumption no longer places a burden on the application developer to map remote servers with session instances.

3) Only sending the peer certificate instead of certificate chains can greatly reduce the data usage of a full TLS handshake.  This will require the receiver to know about the root CAs and intermediate CAs ahead of time but it can often be worth it.

4) Use the shortest MAC you can, but still with good security.  This is probably SHA1 for now.  As more implementations begin to support truncated HMAC you could have the best of both.  SHA-384 for example, but truncated to 10 bytes.

5) Group output messages.  wolfSSL has the ability to send each TLS record individually or to send each group as flight.  This is a small savings, mainly in IP/TCP/TLS record headers but it adds up over time.

6) Use compression at the TLS level if you`re not doing it at the application level.  No sense in doing it twice though.

Did you like the addition of SNI in the last wolfSSL release? If so, you probably will like the Maximum Fragment Length extension as well!

TLS specifies a fixed maximum plaintext fragment length of 2^14 bytes. It may be desirable for constrained clients to negotiate a smaller maximum fragment length due to memory or bandwidth limitations. To enable the usage of Maximum Fragment Length at wolfSSL you can simply do:

./configure –enable-maxfragment

Using Maximum Fragment Length on the client side requires an additional function call, which should be one of the following functions:

wolfSSL_CTX_UseMaxFragment()
wolfSSL_UseMaxFragment()

wolfSSL_CTX_UseMaxFragment() is most recommended when the client would like to contact the same server multiple times with the same configuration. Setting the Maximum Fragment Length extension at context level will enable it in all SSL objects created from that same context from the moment of the call forward.

wolfSSL_UseMaxFragment() will enable it for one SSL object only, so it`s recommended to use this function when the maximum possible length between sessions changes.

On the server side no call is required. The server will automatically attend to the client`s request for Maximum Fragment Length. It is the client`s responsibility to choose the proper length.

Both SNI and Maximum Fragment Length extensions can be enabled with either:

./configure –enable-sni –enable-maxfragment

OR

./configure –enable-tlsx

If you have any questions about using Maximum Fragment Length with TLS please let us know at facts@wolfssl.com.

We would like to announce to our community that Gearman, a framework designed to distribute tasks to multiple machines or processes, now has SSL/TLS support using the wolfSSL lightweight SSL library.

From the Gearman site, Gearman “allows you to do work in parallel, to load balance processing, and to call functions between languages. It can be used in a variety of applications, from high-availability web sites to the transport of database replication events. In other words, it is the nervous system for how distributed processing communicates.”

If you are interested in using Gearman with wolfSSL, Brian Aker explains how to do so in this Google Groups post: https://groups.google.com/forum/?fromgroups#!topic/gearman/kHvarqZ6OYk.

Gearman: http://www.gearman.org/

The bi-monthly release of wolfSSL, 2.7.0, is now ready to download from our website.  New features include:

– SNI (Server Name Indication) for both the client and server with –enable-sni
– KEIL MDK-ARM project files in IDE/MDK-ARM
– Domain name match checks now included wildcard and Subject altname checks by default
– More consistent error returns across all APIs
– Authority Subject ID support for Certificate matching
– Persistent session and certificate cache functionality
– Client session table lookups at the library level instead of making the application cache the sessions
– Camellia support for the SSL sniffer
– User controllable settings for DTLS timeout values
– DTLS reliability enhancements for the handshake
– Better ThreadX support out of the box

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

We receive a lot of questions about the origins of the CyaSSL lightweight SSL library and wolfCrypt software packages.  We get asked where they were developed, and by who?  These questions usually come from US government agencies and their contractors.  Simply stated, mes amis, CyaSSL and wolfCrypt were Born in the USA and written by US citizens.

If you have any additional questions about the origins of CyaSSL or wolfCrypt, please contact us at facts@wolfssl.com

The wolfSSL lightweight SSL package is used by a healthy chunk of Keil users.  In the interest of better enabling our Keil MDK-ARM users, we`ve added MDK-ARM 4 support and documented it here:  http://www.yassl.com/yaSSL/cyassl-keil-mdk-arm.html.

What`s next?  MDK-ARM 5 support.  MDK-ARM 5 will make setup and integration even easier!  Let us know if you are interested in beta testing wolfSSL with MDK-ARM 5 at facts@wolfssl.com.

Up to now, wolfCrypt cryptography library users have had to use it as a part of wolfSSL.  We are now embarking on the project to separate the two, and when finished should have a separate wolfCrypt download for our users that only need to use our crypto.  Our goals are to make the separate downloads easy to maintain and easy to set up.  If you are a wolfCrypt user, and have concerns or comments on how we do this, then please contact us at facts@wolfssl.com.

Have you ever wondered how to use SNI with the wolfSSL embedded SSL library? SNI is useful when a server hosts multiple
‘virtual’ servers at a single underlying network address. It may be desirable for clients to provide the name of the server which it is contacting. To enable SNI with wolfSSL you can simply do:

./configure –enable-sni

Using SNI on the client side requires an additional function call, which should be one of the following functions:

wolfSSL_CTX_UseSNI()
wolfSSL_UseSNI()

wolfSSL_CTX_UseSNI() is most recommended when the client contacts the same server multiple times. Setting the SNI extension at the context level will enable the SNI usage in all SSL objects created from that same context from the moment of the call forward.

wolfSSL_UseSNI() will enable SNI usage for one SSL object only, so it is recommended to use this function when the server name changes between sessions.

On the server side one of the same function calls is required. Since the wolfSSL server doesn`t host multiple `virtual` servers, the SNI usage is useful when the termination of the connection is desired in the case of SNI mismatch. In this scenario, wolfSSL_CTX_UseSNI() will be more efficient, as the server will set it only once per context creating all subsequent SSL objects with SNI from that same context.

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

Are you interested in using the wolfSSL lightweight SSL/TLS library with version 6 of the Microchip TCP/IP stack? If so, you’re in luck! We recently added support for version 6 to wolfSSL. Now wolfSSL supports running on top of either version 5 or version 6 of the stack.

We have updated not only our library source code, but also our example PIC32 SSL client and server. You can find more details on our PIC32-specific webpage, here: http://yassl.com/yaSSL/cyassl-pic32.html.

To download the latest version of wolfSSL with support for Microchip TCP/IP version 6, please see our GitHub repository (https://github.com/cyassl/cyassl). Support will also roll into our next stable release of wolfSSL in June.

wolfSSL Product Page: http://yassl.com/yaSSL/Products-cyassl.html
Microchip TCP/IP Stack: https://www.microchip.com/SWLibraryWeb/product.aspx?product=TCPIPSTACK