Month: June 2013

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