RECENT BLOG NEWS

Larry Stefonic is one of the co-founders of wolfSSL, a company that develops SSL/TLS and cryptography libraries for adding security to devices and applications. wolfSSL began when Larry saw a need for proper security in embedded devices and knew that it was possible to develop a more lightweight SSL implementation. His main goal for wolfSSL is producing and maintaining secure, clean, and readable code, which can be a challenge with today’s rapidly advancing security technology. wolfSSL’s products are included in many different and unique markets ranging from embedded devices to enterprise solutions. His goal is to lead wolfSSL into the top spot in SSL deployments worldwide. Currently, wolfSSL has secured over 1 billion connections and this number is growing rapidly.

Being one of the leaders at one of the world’s top notch Internet security corporations, Larry strives to build a company that not only provides top of the line security software, but also connects cultures around the world. His vision for building wolfSSL includes a meta-national philosophy that melds and augments different ideas and viewpoints from various unique cultures. This worldly advantage contributes to wolfSSL’s tremendous success.

Larry enjoys every aspect of his work at wolfSSL, but he is most fond of developing the team environment. This team includes employees throughout the United States as well as around the globe. The company hosts weekly engineering and team meetings where they discuss current and future projects and ideas and maintain a close working relationship, even if separated by oceans, languages, and cultures.

On a more personal level, Larry is a graduate of Purdue University, and still enjoys following Boilermaker sports. He still enjoys a healthy and active lifestyle and has competed in a number of marathons.  

To learn more about Larry Stefonic and wolfSSL, feel free to explore the company web site at wolfssl.com.

About the Author
Leah Thompson is a development intern at wolfSSL in Bozeman, Montana. She is currently studying at Montana State University, working towards her master’s degree in Computer Science. She enjoys living in the great state of Montana, taking advantage of everything it has to offer including mountain biking, golfing and skiing. Leah is excited to be a part of such a great company and is learning more than she ever thought possible from the experienced team at wolfSSL.

For those of you interested in how CyaSSL fits into IoT, here is an example you should take a look at!

We have prepared a demo with CyaSSL, Xively, and mbed. It runs on various mbed platforms with Ethernet connections, including NXP LPC1768 whose RAM size is as small as 32k for applications + 32k for drivers.

In the demo configuration, mbed sends sensor data every 10 seconds through SSL to the Xively server, and you can see it through the browser on your pc.

 “mbed with Sensors” –[https]–> “Xively Server” <–[https]– “Browser on PC”

Xively is a cloud IoT service. It provides both HTTP and HTTPS APIs for IoT clients, in which they highly recommend HTTPS for obvious reasons, especially for commercial applications.

The demo includes the CyaSSL-based https client class. It is forked from the standard mbed http client class. So you can find out how it can be embedded into a socket-based program as well.

To use the project, please go to our mbed site and import the demo.

http://mbed.org/users/wolfSSL/

http://mbed.org/users/wolfSSL/code/CyaSSL-Xively/

For more information:

Xively: http://xively.com

mbed: http://mbed.org

mbed HTTPClient class:

    http://mbed.org/users/donatien/code/HTTPClient/

    http://mbed.org/handbook/TCP-IP-protocols-and-APIs

Understanding the stack and the heap are fundamental steps for all software developers. The importance of such understanding is inversely proportional to the amount of memory available on the platform, as both compete for a piece of the total memory space available on a system.

In some cases the developer has the choice of when to use one (either the stack or heap) more than the other. In other cases, a scenario may force the developer to work with minimal use of the stack, the heap, or both.

With this in mind, wolfSSL is introducing a new build option in CyaSSL. Developers can now choose a CyaSSL build that best matches their needs of using more stack and less heap OR more heap and less stack. This process is being accomplished by the refactoring of the CyaSSL code. Currently 90% of the encryption layer has been refactored to use the new option.

Small stack usage is not enabled by default. To enable it users must use the option “–enable-small-stack” when configuring the CyaSSL build as in the following example:

./configure –enable-small-stack [other options]

For users who don`t use CyaSSL`s configure script for compilation, smaller stack usage is not enabled by default. In this case, users will need to add the compiler directive CYASSL_SMALL_STACK in config.h file or settings.h to enjoy its benefits as in the following example:

#define CYASSL_SMALL_STACK

or

#define CYASSL_SMALL_STACK 1

If you have any questions about stack usage with CyaSSL please let us know at facts@wolfssl.com.

Hi!  Some of you know that the IETF working group on TLS is creating the specification for TLS 1.3.  We plan to upgrade wolfSSL to the TLS 1.3 specification as soon as the spec is finalized, or even close to finalized.  We are always aggressive with implementing the new TLS specifications, because we like to supply the community with a good test bed.  We did a great job getting TLS 1.2 out right away, as well as DTLS 1.2, and the community appreciated the effort.  We plan to continue our tradition of being quick with new protocol level changes.  

If you`re interested in what TLS 1.3 thinking is so far, then look here:  https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf.  If you have TLS 1.3 questions or comments, you are welcome to email us at facts@wolfssl.com or call us at +1 425 245 8247.

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

– FIPS release candidate
– X.509 improvements that address items reported by Suman Jana with security researchers at UT Austin and UC Davis
– Small stack size improvements, –enable-smallstack. Offloads large local variables to the heap. (Note this is not complete.)
– Updated AES-CCM-8 cipher suites to use approved suite numbers.

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

Hi!  We`ve scheduled ourselves to implement ChaCha20 and Poly1305 into wolfSSL this summer.  If you`re learning about what these are, see these links:

http://cr.yp.to/mac.html

https://www.imperialviolet.org/2013/10/07/chacha20.html

We`re excited about this addition to our code.  If you have comments, questions, or need it in our code sooner than this summer, then let us know!  We can be reached at facts@wolfssl.com or by phone at +1 425 245 8247.

As a follow up to the recent Heartbleed bug in OpenSSL, Embedded Computing Design interviewed wolfSSL’s CTO, Todd Ouska for an article titled “Heartbleed: (Not) one in a million”. You can read the article at the following URL:

http://embedded-computing.com/20937-heartbleed-not-one-in-a-million

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.