RECENT BLOG NEWS

The wolfSSL lightweight SSL package is used by a healthy chunk of Keil users.  In the interest of better enabling our Keil MDK-ARM users, we`ve added MDK-ARM 4 support and documented it here:  http://www.yassl.com/yaSSL/cyassl-keil-mdk-arm.html.

What`s next?  MDK-ARM 5 support.  MDK-ARM 5 will make setup and integration even easier!  Let us know if you are interested in beta testing wolfSSL with MDK-ARM 5 at facts@wolfssl.com.

Up to now, wolfCrypt cryptography library users have had to use it as a part of wolfSSL.  We are now embarking on the project to separate the two, and when finished should have a separate wolfCrypt download for our users that only need to use our crypto.  Our goals are to make the separate downloads easy to maintain and easy to set up.  If you are a wolfCrypt user, and have concerns or comments on how we do this, then please contact us at facts@wolfssl.com.

Have you ever wondered how to use SNI with the wolfSSL embedded SSL library? SNI is useful when a server hosts multiple
‘virtual’ servers at a single underlying network address. It may be desirable for clients to provide the name of the server which it is contacting. To enable SNI with wolfSSL you can simply do:

./configure –enable-sni

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

wolfSSL_CTX_UseSNI()
wolfSSL_UseSNI()

wolfSSL_CTX_UseSNI() is most recommended when the client contacts the same server multiple times. Setting the SNI extension at the context level will enable the SNI usage in all SSL objects created from that same context from the moment of the call forward.

wolfSSL_UseSNI() will enable SNI usage for one SSL object only, so it is recommended to use this function when the server name changes between sessions.

On the server side one of the same function calls is required. Since the wolfSSL server doesn`t host multiple `virtual` servers, the SNI usage is useful when the termination of the connection is desired in the case of SNI mismatch. In this scenario, wolfSSL_CTX_UseSNI() will be more efficient, as the server will set it only once per context creating all subsequent SSL objects with SNI from that same context.

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

Are you interested in using the wolfSSL lightweight SSL/TLS library with version 6 of the Microchip TCP/IP stack? If so, you’re in luck! We recently added support for version 6 to wolfSSL. Now wolfSSL supports running on top of either version 5 or version 6 of the stack.

We have updated not only our library source code, but also our example PIC32 SSL client and server. You can find more details on our PIC32-specific webpage, here: http://yassl.com/yaSSL/cyassl-pic32.html.

To download the latest version of wolfSSL with support for Microchip TCP/IP version 6, please see our GitHub repository (https://github.com/cyassl/cyassl). Support will also roll into our next stable release of wolfSSL in June.

wolfSSL Product Page: http://yassl.com/yaSSL/Products-cyassl.html
Microchip TCP/IP Stack: https://www.microchip.com/SWLibraryWeb/product.aspx?product=TCPIPSTACK

Are you looking for an SSL/TLS library which will seamlessly integrate into your bare metal or No-OS environment? If so, continue reading to learn why the wolfSSL lightweight SSL library is a perfect fit for such environments.

wolfSSL has been designed with portability and ease of use in mind, allowing developers to easily integrate it into a bare metal or operating systemless environment. As a large percentage of wolfSSL users are running the library on small, embedded devices, we have added several abstraction layers which make tying wolfSSL into these types of environments an easy task.

Available abstraction layers include:
+ Custom Input/Output
+ Standard C library / Memory
+ File system (Able to use cert/key buffers instead)
+ Threading
+ Operating System

In addition to abstraction layers, we have tried to keep wolfSSL’s memory usage as low as possible. Build sizes for a complete SSL/TLS stack range from 20-100kB depending on build options, with RAM usage between 1-36kB per connection.

To learn more about how to integrate wolfSSL into your environment or get more information about reducing wolfSSL’s memory usage, please see the wolfSSL Manual or contact us directly.

At wolfSSL we`ve been focusing on SSL/TLS/DTLS technology for 9 years.  We believe that`s important, and if you`re looking for an SSL provider for licenses, support, or custom consulting that may be important to you as well.  Some of our competitors have gone out of business, been sold to larger companies focused on other technologies, or have started on new technologies themselves.  For us, having a day to day primary interest in SSL is beneficial in providing a highly portable, lightweight, fast, up to date, scaleable, full featured solution.  If you`re looking at SSL solutions, we`d love to hear what`s important to you in a provider; we believe our focus on SSL will prove to be a good match for your requirements.

In an effort to ensure that the wolfSSL lightweight SSL library operates seamlessly with the Keil tools, we have recently added MDK-ARM 4 project files to our package.  Additionally, we have added support for Keil RTX.  Information on MDK-ARM 4 can be found here:  http://www.keil.com/arm/mdk.asp.  Information on RTX can be found here: http://www.keil.com/arm/rl-arm/kernel.asp.  Support is currently in beta.  Let us know if you would like to check it out by contacting us at facts@wolfssl.com.

We will also be adding support for Keil MDK-ARM 5, when it comes out of beta.

Many developers are now starting to think about IPv6 and what implications this will have on existing and future projects. IPv6 is becoming increasingly widespread and adoption will further continue to increase into the future.

As a developer, project manager, or curious individual, you may be faced with finding an SSL library which is compatible with IPv6. If so, rest assured! The wolfSSL embedded SSL library is compatible with both IPv4 and IPv6! The library itself has been designed to be IP neutral and work with either protocol version. In addition, we provide an easy-to-use build option to IPv6-enable our example applications for testing purposes.

To turn on IPv6 support when compiling wolfSSL and our example applications, use the “–enable-ipv6” build option:

./configure –enable-ipv6

Addresses beginning with fe80:: are link-local only. These addresses require an interface or scopeid suffix. For example, if ifconfig shows something similar to this:

inet6 fe80::62c5:47ff:fe97:ac2c%en1 prefixlen 64 scopeid 0x6

You could ping this address by doing either:

ping6 -I en1 fe80::62c5:47ff:fe97:ac2c

or

ping6 fe80::62c5:47ff:fe97:ac2c%en1

To start the wolfSSL example server using IPv6, remember to use the “-b” option to bind the server to any interface (unless localhost only is desired):

./examples/server/server -b

If an example wolfSSL example server was running on another link-local host (started with the “-b” option), a wolfSSL client could connect to it by doing something similar to:

./examples/client/client -h fe80::20c:29ff:fedc:e701%en1

Curious about how widespread IPv6 currently is? Google currently tracks IPv6 adoption here: http://www.google.com/ipv6/statistics.html, and you can see how many IPv6 hits/second Akamai is getting here: http://www.akamai.com/ipv6.

If you have any questions about how to use wolfSSL with IPv6, or general questions about using wolfSSL embedded SSL or CTaoCrypt in areas such as the Internet of Things, smart energy, home automation, M2M communication, or cloud services, please get in touch with us at facts@wolfssl.com.

Sick of all the tax day giveaways that you don`t really need, or worse, have to wait in line for?  How about a no wait release of CyaSSL 2.6.0 instead?  New features include:

– DTLS 1.2 featuring AEAD ciphers.  We`re excited about this feature and welcome any feedback.

-SHA-3 finalist Blake is now supported.  Blake2b is extremely fast and uses very little resources, so we like it a lot.

– Support for SHA-384 cipher suites including ECC ones is included as well.  And if you ever need to do HMAC with SHA-512 that`s now supported as well.

– The example client/server can now track memory and stack use with -t and –enable-stacksize respectively.

– IPv6 examples/tests now allow link-local with scopeid resolution and full ipv6 addresses instead of defaulting to localhost.  As before, use –enable-ipv6 to turn on IPv6 in the examples and don`t forget -b on the server to bind to any interface.

– CYASSL_GENERAL_ALIGNMENT manipulates the SSL input/output buffers to align crypto access for easier integration with hardware support.  SSL itself isn`t very friendly to alignment with 5 byte TLS headers and 13 byte DTLS buffers, but we think we have a good solution for this.

– Many new ./configure options including disable/enable for rsa, dh, dsa, md5, sha, arc4, null (ciphers), oldtls, and asn (no certs or public keys allowed).  ./configure options are all lowercase now for better consistency.  A cyassl/options.h header is also now generated during the ./configure process that allows a user to easily use the same settings/flags that cyassl itself was built with.

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

Happy Tax Day,
Team wolfSSL

TLS requires both end points to have received and processed their peer`s Change Cipher Spec and Finished messages before starting to transfer their bulk encrypted data. It needs the Finished message to validate its peer`s identify. To save one round-trip time, an endpoint after having sent its Finished message could start sending its encrypted data using that cipher specification.

wolfSSL currently does not directly support TLS False Start, but it is tolerant of a peer sending its data immediately after sending its Finished message. It just will not send encrypted data to its peer until it has completed its handshake.

Do you need wolfSSL to handle TLS False Start? Contact us at facts@wolfssl.com.