RECENT BLOG NEWS

wolfSSL is a growing company looking to add a top notch embedded systems software developer to our organization. We develop, market and sell the leading open source embedded SSL protocol implementation, CyaSSL. We are also the developers of the yaSSL Embedded Web Server and wolfCrypt Crypto Engine. Our users are primarily building devices or applications that need security.

Operating environments of particular interest to us include Embedded Linux, VxWorks, QNX, ThreadX, FreeRTOS, and ARM RTX. Skill with the new mobile and embedded environments like Android and iOS is a plus.

Currently, we are seeking to add a master level C developer interested in a fun young company with tremendous upside.

Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.

To apply or discuss, please contact larry@wolfssl.com.

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.

If you are a Keil MDK-ARM user, we’re happy to announce that the wolfSSL embedded SSL library is now integrated into the Keil MDK5 as an easy-to-use software pack.

This integration means that MDK5 users can easily pull in SSL/TLS support directly to their Keil projects without going out to the web to do a separate download. In addition to the library itself, several example projects using wolfSSL are also available.

As stated by Reinhard Keil, ARM’s Director of MCU Tools, “The Keil and wolfSSL teams have successfully collaborated to fully integrate CyaSSL Embedded SSL into MDK 5. The result is the most seamless tool combination available for developers wishing to secure their device communications with SSL.”

To read more, the press release can be found here: http://www.prweb.com/releases/2013/10/prweb11215195.htm. We’re excited to hear user feedback and field any questions that may come up. Let us know what you think at facts@wolfssl.com.

wolfSSL is happy to announce that the first release of the wolfSSL JNI wrapper is now available for download.

wolfSSL JNI provides Java applications with SSL/TLS support up to the current industry standards of TLS 1.2 and DTLS 1.2.  Current Java implementations have lacked DTLS support, causing Java developers to write their own custom JNI wrapper if they wanted or needed to use DTLS.  wolfSSL JNI solves this problem by giving developers a ready-to-use Java wrapper around the robust and mature CyaSSL lightweight SSL library.

In addition to providing DTLS support, wolfSSL JNI has been designed with flexibility in mind.  It allows Java applications to write custom callbacks for I/O, public key, MAC/encrypt, decrypt/verify, and logging, and allows developers to leverage all the flexibility and portability that has made CyaSSL popular with users around the globe.

Like CyaSSL, wolfSSL JNI is dual licensed under both the GPLv2 as well as a standard commercial license.  Detailed licensing and support options can be found on the wolfSSL Licensing page (linked below).

Download wolfSSL JNI and give it a try!  If you have any questions or comments, please feel free to reach out to us at facts@wolfssl.com.

Download:  https://www.wolfssl.com/download/
wolfSSL JNI Manual: http://www.yassl.com/yaSSL/Docs-wolfssl-jni-manual.html
wolfSSL JNI Product Page:  http://yassl.com/yaSSL/Products-wolfssljni.html
License Information:  http://yassl.com/yaSSL/License.html

Hi!  We are currently considering implementing Oauth for devices.  

OAuth, first defined by RFC 5849 (1.0), and revised with RFC 6749 (2.0) specifies an authorization framework to allow third party applications to obtain limited access to HTTP services.  From RFC 6749:

“In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner`s credentials.  In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party.”

Under this traditional approach, third parties are given direct access to the resource owner`s credentials.  This brings with it several concerns, including passwords being stored in plaintext, third parties gaining overly-broad access to the resource owner`s resources, and the inability for resource owners to revoke third party privileges without having to change their password.

OAuth presents a way to solve these issues by having the third party application request access to resources controlled by a resource owner (which are hosted on a resource server).  The application is then issued a different set of credentials than those of the resource owner which it can then in turn use to access the desired resources.

Do you need an OAuth client on your device or for your embedded application?  If so, let us know at facts@wolfssl.com.

RFC 5849:  http://tools.ietf.org/html/rfc5849
RFC 6749:  http://tools.ietf.org/html/rfc6749
OAuth Community Site:  http://oauth.net/

Hi!  This is just a reminder.  We are still all about open source.  We believe that Open Source Software is the best way to conceive, share, deliver, support and build software.

We believe in open source for all of the right and well documented reasons.  If you can`t work with open source then tell us your story at facts@wolfssl.com.