RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news, or sign up to receive weekly email notifications containing the latest news from wolfSSL. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

Announcing the yaSSL Embedded Web Server

As stated in previous blog posts, we have ported wolfSSL into a number of embedded web servers on behalf of our customers and community users.  wolfSSL can be included in Mongoose , Lighttpd (aka Lighty), Nginx, GoAhead, and others.  As a part of the work of enabling these embedded web servers to use SSL, we have learned a lot about all of these excellent products, including how they are used in embedded environments, what their code is like, and their feature support. 
 
As a result of our evaluation, we put a lot of energy into determining which open source embedded web server should receive the bulk of our attention.  We want to focus on the one that maps most closely to the needs of our customer base.  The wolfSSL customer generally wants the following in their open source embedded web server, in order of priority:
 
1.       Support for real time and embedded operating systems.
2.       Commercially available support
3.       Size:  Small, tight code.
4.       Well enabled security features
5.       Speed
 
As a result of our evaluation, we determined that the Mongoose embedded web server should receive the bulk of our attention.  Mongoose is the winner because it fits our customer’s needs, via the following metrics:
 
1.       Default size, with wolfSSL enabled, of less than 200k.
2.       Excellent code base and community.
3.       Portability to real time and embedded operating systems.
 
Based on all of the above, and more, we have decided to sell and market a version of Mongoose we’re calling the yaSSL Embedded Web Server.  We have agreed with the leader of the Mongoose community, Sergey Lyubka, to collaborate on feature development and bug fixes.  Bug fixes, feature additions, and general improvements that we generate to the code base will be rolled back into the main source tree subject to Sergey’s approval.  We will endeavor to be a good citizen and quality partner to the Mongoose community!
 
Versions of the yaSSL Embedded Web Server for RTOS and embedded environments are available immediately, upon request, on a subscription basis.  Annual subscriptions are available at the price of $5,000 USD per year.  Subscriptions include the following, per product line within which you embed: 
 
1.       Commercial support for wolfSSL and the yaSSL Embedded Web server
2.       Updates and upgrades
3.       Porting of both the SSL and Web Server to your  embedded environment and chipset.
4.       Commercial licenses
5.       Size and speed optimization support
 
Supported environments include ThreadX, VxWorks, QNX, OpenWRT, Tron, iTron, Microitron, Android, OpenCL, and MontaVista.  Other supported environments are available on a per request basis.  We’ll also support *nix and the gaggle of *bsd’s, which we’ll port to as requested. 
 
As always, we’d like your feedback and questions!  Please contact us at info@yassl.com.

wolfSSL competitive upgrade program now available

Competitive upgrade pricing for wolfSSL is now available.  We’ll help you move from an outdated or expensive ssl library to wolfSSL with low cost and minimal disturbance to your code base.    
 
How does it work?  Here’s an outline of the program:
 
1. You need to currently be using a commercial competitor to wolfSSL.
2. You will receive up to two weeks of onsite consulting to switch out your old ssl library for wolfSSL.  Travel expenses are not included.
3. Normally, two weeks is the right amount of time for us to make the replacement in your code and do initial testing.  Additional consulting on a replacement is available as needed.
4. You will receive the standard wolfSSL royalty free license to ship with your product.
5. The price is $10,000.
 
The purpose of this program is to enable users who are currently spending too much on their embedded ssl implementation to move to wolfSSL with ease.  If you are interested in learning more, then please contact us at info@yassl.com.

CyaSSL SSL Provider for Android Released – Alpha Version

We have released an Alpha of our Java SSL Provider for the Android Platform.  This can be installed alongside the existing Apache Harmony provider and can be used through the javax.net.ssl Java API package.  By using our provider, Java developers can use familiar syntax and API calls of Java to gain the speed and size advantages that the CyaSSL embedded SSL library offers.  By using CyaSSL on Android, you can reduce the overall image footprint by 500k to 600k.

Being in the Alpha stage, this provider currently only offers client functionality.  If you want to give our provider a try, please download it from our additional downloads page here.  Instructions for installation into the Android Platform can be found in the README file included with the download.

We look forward to your feedback!  Please keep in mind that this is an alpha release.  Please contact us at info@yassl.com if you need support.

Encrypted Memcached beta 1 and beta 2 – memcache with integrated CyaSSL embedded ssl

Hi!  Two months ago we announced the availability of a version of memcached that we’ve been calling secure memcached.  This current branch of memcached includes ssl encryption between client and server.  Currently, client support is limited to libmemcached, but we’ll work with our beta sites to support additional clients as needed.  Our plan is to submit our branch as a patch to the project once we receive more feedback from betas.

Our upcoming Beta 2 version of secure memcached will add encryption for data held inside the server.  As such, if someone gets their hands on your memcached server, they won’t be able to read the data.  The level of security in Beta 2 will resolve the vulnerability faced by memcached users recently discussed on Slashdot:  http://it.slashdot.org/story/10/08/07/035255/Cache-On-Delivery-mdash-Memcached-Opens-an-Accidental-Security-Hole.

Beta 2 is slated for release in a couple of weeks.  Please contact us at info@yassl.com if you would like to participate in the beta program.


For performance results for secure memcache, please contact us.

A copy of our presentation on secure memcached  given at OSCON is available here:  PPT Download

Using wolfSSL embedded SSL on iPhone

Many of our users are unaware that the wolfSSL embedded SSL/TLS library is available for iPhone. The first question to answer is why did we port wolfSSL to the iphone in the first place?  The answer to that question is simple:  our primary development environment is Mac OSX and we walk around town with iOS in our pockets.  As such, it was right in front of us and ready to play with.
 
What can you do with an iPhone embedded ssl library?  Build your application with SSL included for enhanced security!  If you need to secure any iOS app and you want to use the de facto SSL API, then choose wolfSSL.  It is small, and will add minimal size to your application download.  You could use it to secure personal data, financial data, etc.  And, don’t forget that wolfSSL is cross platform, so it will run on other devices that you port your application to. 
 
To get yourself started, wolfSSL maintains an Xcode iOS project in the wolfSSL library, which can be downloaded from our download page here: https://www.wolfssl.com/download/. 

If you have any questions on using wolfSSL in your iOS application, please contact us at facts@wolfssl.com.

It’s the Final Countdown

wolfSSL is about to make its alpha test debut as a Java based SSL provider on Android.  This project took longer than planned, but we now have a version working internally.  Alpha releases are available on a request basis.  We’ll post more here as we make it available early next week. 
 
In the meantime, for your listening and viewing pleasure:  http://www.youtube.com/watch?v=7_IKcMl_a9A.

wolfSSL embedded ssl and OpenWRT

There’s a great article on “Building Custom Firmware with OpenWRT” in the August edition of Linux Journal:  www.linuxjournal.com.  It’s not out on their website yet, but is available in paper form if you pick up a copy. 
 
If you haven’t checked out the OpenWRT project yet, you can do so here:  www.openwrt.org.  We’ve been supporting OpenWRT for a couple of years now with our wolfSSL embedded ssl implementation, and it had now been adopted by quite a few OpenWRT applications and derivatives.  A couple of examples include:  http://www.gargoyle-router.com/, who hacked wolfSSL down even much smaller than the normal 50k, and LuCi, http://luci.subsignal.org/.
 
If you’re using wolfSSL in an open source project, keep in mind that our policy is to support open source projects for free, as in free beer at our SSL party.  It will rock.  As such, you can channel your questions directly to our forums http://sourceforge.net/projects/yassl/forums/forum/439591, or if they are sensitive, email them to us at info@yassl.com. 
 
Rock on!

What’s the difference between wolfSSL and OpenSSL

We’re often asked what differentiates wolfSSL and OpenSSL.  Here’s our list: 
 
a. wolfSSL builds are 20-40 times smaller than OpenSSL.  Hence it is much more useful in embedded ssl implementations.
b. Standards support:  wolfSSL supports TLS 1.1 and 1.2.  OpenSSL does not support TLS 1.1 or 1.2.
c. wolfSSL was built with securing streaming media in mind.  OpenSSL was built before streaming media was popular on the internet. As such, wolfSSL supports the latest streaming ciphers like Rabbit and HC-128 where OpenSSL does not.
d. License:  wolfSSL is GPLv2 or commercial, with a company behind the commercial license.  OpenSSL does not have a clear license. 
e. We have tried to apply Occam’s razor as the guiding philosophy to our implementation of SSL.  As such, our API focuses on the most critical and necessary functionality in order to simplify the problem.  wolfSSL has 20 or so function calls,  and an additional 230 for our OpenSSL compatibility layer.  OpenSSL has over 3,500.
f. Really old code versus relatively new code:  wolfSSL was written starting in 2004.  OpenSSL started in 1995.  Coding standards and requirements are a lot different now.  OpenSSL has a longer legacy to support and maintain.
g. The OpenSSL legacy code comes from supporting usage profiles and operating systems that are no longer mainstream.  The legacy code makes OpenSSL a easier to break and harder to fix. 
h. OpenSSL was written as the SSL/TLS standards were being defined.  Their code went down a number of blind alleys.  We had the luxury of writing our code once the standards were well settled.
 
Please contact us at info@yassl.com if you have comments!  We’ll be happy to re-factor this list with your input!

It’s the Final Countdown

wolfSSL is about to make its alpha test debut as a Java based SSL provider on Android.  This project took longer than planned, but we now have a version working internally.  Alpha releases are available on a request basis.  We’ll post more here as we make it available early next week. 
 
In the meantime, for your listening and viewing pleasure:  http://www.youtube.com/watch?v=7_IKcMl_a9A.

What’s the difference between wolfSSL and OpenSSL

We’re often asked what differentiates wolfSSL and OpenSSL.  Here’s our list: 
 
a. wolfSSL builds are 20-40 times smaller than OpenSSL.  Hence it is much more useful in embedded ssl implementations.
b. Standards support:  wolfSSL supports TLS 1.1 and 1.2.  OpenSSL does not support TLS 1.1 or 1.2.
c. wolfSSL was built with securing streaming media in mind.  OpenSSL was built before streaming media was popular on the internet. As such, wolfSSL supports the latest streaming ciphers like Rabbit and HC-128 where OpenSSL does not.
d. License:  wolfSSL is GPLv2 or commercial, with a company behind the commercial license.  OpenSSL does not have a clear license. 
e. We have tried to apply Occam’s razor as the guiding philosophy to our implementation of SSL.  As such, our API focuses on the most critical and necessary functionality in order to simplify the problem.  wolfSSL has 20 or so function calls,  and an additional 230 for our OpenSSL compatibility layer.  OpenSSL has over 3,500.
f. Really old code versus relatively new code:  wolfSSL was written starting in 2004.  OpenSSL started in 1995.  Coding standards and requirements are a lot different now.  OpenSSL has a longer legacy to support and maintain.
g. The OpenSSL legacy code comes from supporting usage profiles and operating systems that are no longer mainstream.  The legacy code makes OpenSSL a easier to break and harder to fix. 
h. OpenSSL was written as the SSL/TLS standards were being defined.  Their code went down a number of blind alleys.  We had the luxury of writing our code once the standards were well settled.
 
Please contact us at info@yassl.com if you have comments!  We’ll be happy to re-factor this list with your input!

Running wolfSSL on a GPU

Hi!  wolfSSL is ported to both the Cuda http://en.wikipedia.org/wiki/CUDA  and OpenCL http://en.wikipedia.org/wiki/OpenCL frameworks.  These frameworks are for writing programs that execute on GPU’s, or Graphical Processing Units.  Generally, GPU’s are used for graphics processing, but due to their high production volumes and low cost, they can be useful for math intensive computing.  Early adopters are building super computers based on GPU’s for various purposes.  For example:  http://hardware.slashdot.org/story/09/12/16/2255259/FASTRA-II-Puts-13-GPUs-In-a-Desktop-Supercomputer.  Search Slashdot for GPU for more examples. 
 
wolfSSL is ported to GPU’s because it is a low cost way to leverage GPU compute power for SSL offload, and can be much more cost effective for building SSL appliances. 
 
Let us know at info@yassl.com if you are interested in running SSL on a GPU.  We’ll be happy to support you!

wolfSSL Java SSL Provider Alpha Released

We have released an Alpha of our SSL Provider for Java.  Currently supporting Mac and Linux operating systems, this provider enables Java developers to use wolfSSL through the javax.net.ssl package.  By using this, Java developers can use familiar syntax and API calls to gain the speed and size advantages that the wolfSSL embedded SSL library provides.

Being in the Alpha stage, this provider currently only offers client functionality.  If you want to give our provider a try, please download it from our additional downloads page here.  Instructions for installation can be found in the README file included with the download.

We look forward to your feedback!

HealthVault applications for iphone and Android using wolfSSL

We`re thinking about implementing the security layer under Java to enable HealthVault applications for iphone and Android using our wolfSSL embedded ssl.  This means we`ll support the proper certificate generation for HealthVault applications that want to allow their users to securely access HealthVault information from iphone and Android devices.  As such, we`re interested in finding HealthVault application providers interested in iphone or Android.  Are you interested in device based HealthVault?  If yes, then please contact us at info@yassl.com.

wolfSSL Embedded SSL for Android

The wolfSSL library for Android is almost ready for alpha testing.  The project has taken us longer than anticipated!  The key benefits to the new technology include:
 
1.       Better performance than Android’s native SSL support through OpenSSL.
2.       Smaller footprint.
3.       Tight, seamless integration with Java as an SSL Provider. 
 
The follow through of the project will also drive release of wolfSSL as a Java based SSL provider on other platforms.  The initial targets are Mac and Linux.  If you are interested in using wolfSSL hosted in Java, then contact us at info@yassl.com.

Mongoose Embedded Web server and wolfSSL Embedded SSL

Hi!  One of our users recently requested that wolfSSL become compatible with Mongoose.  As such, we have recently made changes to the wolfSSL 1.5.4 embedded ssl library to make it build seamlessly with the Mongoose embedded web server.  Essentially this meant that we made minor enhancements to wolfSSL’s openssl compatibility layer to accomplish a clean build.  Everything should build cleanly at this point, but let us know if you face any issues.  If you build with wolfSSL instead of OpenSSL, you will get a smaller resulting build.  You can contact us with any support issues you face at info@yassl.com.

Using AES-NI in the wolfSSL embedded ssl library version 1.5.4

Hi!  Most of our readers will already know that AES is a key encryption standard used by governments worldwide, and that wolfSSL has always supported AES. 
 
Intel has released a new set of instructions that is a faster way to implement AES, and wolfSSL is currently the first ssl library to fully support the new instruction set for production environments. 
 
Essentially, Intel has added AES instructions at the chip level that perform the compute intensive parts of the AES algorithm, boosting performance. 
 
What we’ve done is add the functionality to wolfSSL to allow it to call  the instructions directly from the chip, instead of running the algorithm in software.  This means that when you’re running wolfSSL on a chipset that supports AES-NI, you can run your AES crypto 5-10 times faster! 
 
If you’re doing some benchmarking for your environment, let us know at info@yassl.com we’ll be happy to support you with the effort.  Our current benchmarks are in the lab, and we’d like to work with users that can help us further define real world expectations for speed improvements from AES-NI.
 
References and further reading, ordered from general to specific: 
 
Wikipedia entry on AES:  http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Wikipedia entry on AES-NI:  http://en.wikipedia.org/wiki/AES_instruction_set
Intel Software Network page on AES-NI:   http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-instructions-aes-ni/
 
See the readme of wolfSSL 1.5.4 for instructions on building with AES-NI.

Using the wolfSSL embedded ssl library for digitally signing and authenticating

wolfSSL is a popular tool for digitally signing applications, libraries or files prior to loading them on embedded devices.  Most desktop and server operating systems allow creation of this type of functionality through system libraries, but stripped down embedded operating systems do not.  The reason that embedded RTOS environments do not include digital signature functionality is because it has historically not been a requirement for most embedded applications.  However, the times they are a changing.  In today’s world of connected devices and heightened security concerns, digitally signing what is loaded onto your embedded or mobile device has become a top priority.  Examples of embedded connected devices where this requirement was not found in years past include set top boxes, DVR’s, POS systems, both VoiP  and mobile phones, and even automobile based computing systems.  Because wolfSSL supports the key embedded and real time operating systems, encryption standards and authentication functionality, it is a natural choice for embedded systems developers to use when adding digital signature functionality.
 
Generally, the process for setting up code and file signing on an embedded device are as follows:
 
1. The embedded systems developer will generate an RSA key pair.
2. A server side script based tool is developed
a. The server side tool will create a hash of the code to be loaded on the device with SHA-256 for example.
b. The hash is then digitally signed, also called a RSA private encrypt.
c. A package is created that contains the code along with the digital signature.
1. The package is loaded on the device along with a way to get the RSA public key.  The hash is re-created on the device then digitally verified (also called RSA public decrypt) against the existing digital signature.
 
Benefits to enabling digital signatures on your device:
 
1. Easily enable a secure method for allowing third parties to load files to your device.
2. Ensure against malicious files finding their way on to your device.
3. Digitally secure firmware updates
4. Ensure against firmware updates from unauthorized parties
 
Do you need help setting up code signing for your embedded device?  Let us know as we can help setting up servers side scripts as well as on the device side.  Contact us at info@yassl.com.
 
More background on code signing:
 
A great article on the topic at embedded.com:  http://embedded.com/design/216500493?printable=true
 
General information on code signing:   http://en.wikipedia.org/wiki/Code_signing

Benchmarking an Embedded SSL Library

Hi!  We’re planning to build a benchmark tool for our users.  We believe that developers like to make an informed choice, and benchmarking is the key to getting informed about tools like wolfSSL.  Size and TPS are usually at the top of the agenda when benchmarking an SSL library, but other considerations can come into play as well.  For example, does the library support TLS version 2, or does it only support SSL 3.0 or TLS version 1?  Does the library support DTLS?  How do the various ciphers perform against each other under different load types?

The first version of our SSL benchmark tool will only benchmark wolfSSL, but we hope to expand its scope over time to compare other open source SSL libraries as well.  Please contact us at info@wolfssl.com if you have input on other parameters that should be benchmarked or if you are interested in participating in the development of the tool.  We’re also thinking of breaking with our traditional yet boring “yet another” naming convention and calling the benchmark tool something else, like “Hungry Wolf” or “SSL Slapper” to spice things up.  As such, email us if you think you have a great name idea for the tool!

Posts navigation

1 2 3 … 184 185 186 187 188 189 190

Weekly updates

Archives