RECENT BLOG NEWS

It was reported yesterday in The Guardian and elsewhere that the NSA paid RSA $10M to set Dual_EC_DRBG as their default PRNG.  See the news here:  http://www.theguardian.com/world/2013/dec/20/nsa-internet-security-rsa-secret-10m-encryption.  

As we have previously stated, we never implemented Dual_EC_DRBG in any of our products, much less set it as default, because of its suspect nature.  If you`re not familiar with Dual_EC_DRBG, the background on wikipedia is here:  http://en.wikipedia.org/wiki/Dual_EC_DRBG.

For even more background, here`s a great Black Hat talk by Derek Soeder, Christopher Abad, and Gabriel Acevedo from Cylance on the subject of breaking Pseudorandom Algorithms.

wolfSSL, as a long standing partner to ARM, has always been well optimized for ARM environments. One of the ways CyaSSL can be optimized for ARM platforms includes assembly optimizations for Public Key operations with the CTaoCrypt fastmath option. This translates to a speed increase when using RSA, Diffie-Hellman, DSA, or ECC.

If you dive into our code, these optimizations can be found in the asm.c source file.

When using the ./configure system, fastmath is enabled by default on 64-bit platforms. On 32-bit platforms, it can be enabled by using the “–enable-fastmath” option. In environments not using the ./configure system to build CyaSSL, fastmath can be enabled by defining USE_FAST_MATH. Since stack usage can be high when using fastmath, we recommend defining TFM_TIMING_RESISTANT as well.

If you have any questions about using CyaSSL in an ARM environment, please contact us at facts@wolfssl.com.

We`ve been encouraged by the feedback from the community on dropping SSL 3.0 support from wolfSSL, meaning that people think we should drop it as insecure and eliminate the legacy which goes back to 1996.  Many thanks to Paul Kocher, Phil Karlton, Alan Freier, and the many shoulders they were standing on for designing the SSL 3.0 protocol, but after 17 years, it is time to evolve to a TLS only world.  

Practically speaking, this means that we`ll deprecate SSL 3.0 code from our tree, and only apply critical security fixes.  We will of course support existing customers and open source users that need SSL 3.0 for specific reasons that are private to them.  

It might be fun to think about a name for our Q1 release of wolfSSL without SSL support.  Here`s some ideas:  SSL Minus, SSL Minas Tirith, CaTLS defend Minas Tirith.  It can go on for a while.  See http://en.wikipedia.org/wiki/Minas_Tirith for reference.  Oh, here`s another idea, how about wolfTLS?

Send in your ideas for the new name to facts@wolfssl.com.

Hi!  We`re considering the elimination of SSL 3.0 support from wolfSSL.  There`s a lot of reasons to do it, including better security, cleaning up our code, and its time to move on and modernize.  Anybody have an opinion?  The code would still be available, but not mainline.

Are you fan of TLS Extensions? We are here today to present the addition of Truncated HMAC on wolfSSL!

Currently defined TLS cipher suites use the HMAC to authenticate record-layer communications. In TLS, the entire output of the hash function is used as the MAC tag. However, it may be desirable in constrained environments to save bandwidth by truncating the output of the hash function to 80 bits when forming MAC tags. To enable the usage of Truncated HMAC at wolfSSL you can simply do:

./configure –enable-truncatedhmac

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

wolfSSL_CTX_UseTruncatedHMAC();
wolfSSL_UseTruncatedHMAC();

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

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

On the server side no call is required. The server will automatically attend to the client`s request for Truncated HMAC.

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.

If you`re working with SSL Termination and/or SSL Inspection we have good news for you! wolfSSL now has a new feature in its Server Name Indication API:

wolfSSL_SNI_GetFromBuffer()

This function is capable of retrieving the server name of a given type indicated by the client from the raw bytes of a ClientHello message. This way, it is possible to save both time and resources in order to get the information needed to make a decision, whether that be which path the connection should take or if it should be inspected.

The SNI extension can be enabled with either:

./configure –enable-sni

OR

./configure –enable-tlsx

Remember that the second option will enable all TLS extensions implemented in wolfSSL.  If you`re planning on using more than one extension and still care for a smaller build, you should enable the extensions one by one.

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

All too often, security software vendors resort to fear-mongering as a sales and marketing method.  At wolfSSL, we consciously avoid this tactic.  We recognize that our competitors use it.  They tell customers to be afraid of open source.  They tell customers to be afraid of breaches. Unfortunately, they use the fear mongering approach to their benefit.  However tempting, we reject their approach as fundamentally wrong and immoral.  We understand why they do it, but it is still unethical.

wolfSSL makes sales.  We are an open source project and an open source company.  To succeed at both, we need to generate revenue.  More revenue means that we will produce more open source.  More open source means that we can produce more revenue and subsequently even more open source, and so on.  

An old colleague, Marten Mickos, originally characterized this as the “Beautiful Virtuous Cycle of Open Source” that drove the success of MySQL.  He was right about the cycle, and we at wolfSSL are intent taking a page out of the database book and multi-master replicating it in the security software market.  We believe our dual license strategy, which employs both commercial and GPLv2 licensing, is the best thing for both community and commercial users.  This truth we hold to be self evident, when understood properly.  

We know that open source licensing can be confusing, and we are happy to explain our licensing model.  Please feel free to contact us at licensing (at) wolfssl.com if you have questions.  Our only goal is to help you understand our approach, and help you make a rational decision.  We are happy to help you avoid fear mongering!  Don`t forget that fear is the mind killer!

And now, let us discuss fear-mongering in security.  First of all, don`t believe the hype.  Turn on your sensors.  When the marketing organization of your vendor focuses on breaches rather than on informing you on how to defend against them, you are working with the wrong organization.  A good security software company will strive to inform you and not strive to scare you!  We suggest that you don`t work with an organization that uses the fear-mongering tactic to drive their sales.  Turn on your sensors, don`t let fear be the mind killer, and do the right thing given your situation.

As always, we are here to create community and security.  Please feel free to contact us with your thoughts at facts@wolfssl.com.

And, dear reader, this riddle for you, How Many Haiku`s Send a Message?

Team wolfSSL

Hi!  IoT engineers everywhere are battling with software resource usage.  TCP/IP and SSL can be fairly consumptive of resources.  One of the old school techniques for minimizing resource consumption is swapping one app for another on a device.  Taking that concept to an extreme can be tricky, and the extreme we`ve been working with is swapping between TCP/IP and SSL while maintaining a live connection.  The trick is keeping the connection going.  To get there, we`ve implemented the Swapper!  

If you think the Swapper might help you battle through your resource constraints, then contact us at facts@wolfssl.com.  

As a large number of our users port wolfSSL to new platforms and environments, we’ve put some time into updating our wolfSSL Porting Guide and have made it available both online and in PDF version.

The updated guide covers areas in the wolfSSL code which typically need modification when porting wolfSSL to a new environment, including:

2.1  Data Types
2.2  Endianness
2.3  writev
2.4  Input / Output
2.5  Filesystem
2.6  Threading
2.7  Random Seed
2.8  Memory
2.9  Time
2.10  C Standard Library
2.11  Logging
2.12  Public Key Operations
2.13  Atomic Record Layer Processing
2.14  Features

You can find the updated guide here: wolfSSL Porting Guide.

If you have any questions about content in the Porting Guide, or about the wolfSSL lightweight SSL library in general, please reach out to us at facts@wolfssl.com.