Month: November 2013

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.