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.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.

White Paper: Implementation and Performance of AES-NI in wolfSSL Embedded SSL

yaSSL and Intel have jointly published a white paper describing how Intel’s AES-NI can be used with the wolfSSL embedded SSL library. This paper provides a brief overview of the Intel AES-NI instructions and demonstrates the performance gains realized when Intel AES-NI is used in place of a more traditional software-only based AES implementation. The wolfSSL embedded SSL library developed by yaSSL, is used as a test bed in the white paper to perform the comparison as it can be built with either traditional AES or AES-NI support at compile time. As a secondary goal to demonstrating Intel AES-NI performance, this paper explains how to determine if a pre-built SSL library (static or shared) offers built-in support for the Intel Advanced Encryption Standard New Instructions.

You can download the white paper directly from the yaSSL website at the following location. If you have any questions about using wolfSSL on Intel hardware, please contact us at

wolfSSL AES-NI White Paper: yaSSL White Papers (

More Flexible Example Applications

You may have noticed that with our most recent release of the wolfSSL embedded SSL library (2.3.0), we have made our example client and server applications more flexible and easier to use. These updated applications – client (./examples/client/client) and server (./examples/server/server) – now offer a variety of command line options to adjust things ranging from SSL certificates to protocol version selection.

Looking at the example client application, if you run the app with the “–help” option, you will see a list of supported options:

./examples/client/client –help
client 2.3.1 NOTE: All files relative to wolfSSL home dir
-? Help, print this usage
-h Host to connect to, default
-p Port to connect on, default 11111
-v SSL version [0-3], SSLv3(0) – TLS1.2(3)), default 3
-l Cipher list
-c Certificate file, default ./certs/client-cert.pem
-k Key file, default ./certs/client-key.pem
-A Certificate Authority file, default ./certs/ca-cert.pem
-b Benchmark connections and print stats
-s Use pre Shared keys
-d Disable peer checks
-g Send server HTTP GET
-m Match domain name in cert

Likewise, looking at the server, you can see a variety of command line options available as well:

./examples/server/server –help
server 2.3.1 NOTE: All files relative to wolfSSL home dir
-? Help, print this usage
-p Port to listen on, default 11111
-v SSL version [0-3], SSLv3(0) – TLS1.2(3)), default 3
-l Cipher list
-c Certificate file, default ./certs/server-cert.pem
-k Key file, default ./certs/server-key.pem
-A Certificate Authority file, default ./certs/client-cert.pem
-d Disable client cert check
-b Bind to any interface instead of localhost only
-s Use pre Shared keys

We hope this will make testing connections and wolfSSL builds much easier and less time consuming. If you have any suggestions for future improvement, please let us know at

The CRIME attack and wolfSSL embedded SSL

The CRIME attack has been in the news recently, and some of our users have been asking about it.  The short version of responding to the attack is simple:  disable TLS compression.  In wolfSSL, compression is disabled by default.  The Tor project has posted an excellent explanation of the attack in their blog.  For more details, see:  

If you have questions on this attack in relation to wolfSSL, please contact us at

Avoid BEAST attack when using CyaSSL lightweight SSL implementation

Hi!  To our users concerned about the following security advisory: (as of 26 March 2018 at 9:28am MDT, this link no longer works and has no alternative), it is a vulnerability related specifically to SSL 3.0 and TLS 1.0.  When using CyaSSL, you can avoid this vulnerability using one of several methods, including:

  1. 1. Using a higher level of the SSL/TLS protocol – either TLS 1.1 or TLS 1.2

  2. 2. Using TLS 1.0 or SSL 3.0 with a stream cipher. CyaSSL supports several, including RC4, HC-128, and RABBIT.

3.  If you must use SSL 3.0 or TLS 1.0 with a block cipher, split the first SSL write at the application level into fragments (as modern browsers do).

If you have further concerns or questions, please contact us at

yaSSL at IDF 2012 – AES-NI and RDRAND

yaSSL is attending IDF 2012 (#idf2012) this week in San Francisco.  As exhibitors and visitors are busy talking about the newest technology advancements from Intel and their partners, yaSSL is talking about several Intel technology features related to CyaSSL as well.  CyaSSL currently supports Intel’s AES-NI to accelerate AES operations on supported processors.  In addition, CyaSSL will soon be getting support for Intel’s RDRAND.  To learn more about these features and the CyaSSL embedded SSL library, visit us at booth 424 this week at IDF 2012!

wolfSSL is Now Available in the MacPorts Project

If you are a user of the popular MacPorts project on OS X, you may be happy to hear that the wolfSSL embedded SSL library is now available as a MacPorts package. If you are not familiar with the MacPorts Project, a brief summary from their website does an excellent job of explaining the project. At the time this post was written, there were 15,657 ports in the MacPorts tree.

As stated on their homepage, “The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system. To that end we provide the command-line driven MacPorts software package under a BSD License, and through it easy access to thousands of ports that greatly simplify the task of compiling and installing open-source software on your Mac.

We provide a single software tree that attempts to track the latest release of every software title (port) we distribute, without splitting them into “stable” Vs. “unstable” branches, targeting mainly the current Mac OS X release (10.8, A.K.A. Mountain Lion) and the immediately previous two (10.7, A.K.A. Lion and 10.6, A.K.A. Snow Leopard).”

To install the wolfSSL MacPorts package on OS X, there are only a few simple steps required:

1. Download and install MacPorts (
2. From the OS X terminal, run the command, “sudo port install cyassl”. This will install wolfSSL into the /opt/local directory.

To learn more about MacPorts, please visit their website at

Using Crypto Algorithms Separately from CTaoCrypt

As you may know, CTaoCrypt is the underlying cryptography library used by the wolfSSL embedded SSL library. We’ve had several users choose to use CTaoCrypt’s crypto algorithms because they are easy to isolate and use independently of the library itself. For example, if you need to use MD5 in your own code but don’t want to write it yourself, you could extract CTaoCrypt’s MD5 implementation and use it directly in your code.

Most crypto algorithms in CTaoCrypt are contained within a source file and header file. For MD5, the relevant code would be in ./cyassl/ctaocrypt/md5.h and ./ctaocrypt/src/md5.c. Other algorithms follow the same directory and source file pattern.

If you have any questions about using CTaoCrypt’s algorithms separately, please let us know at As always, feel free to download the GPLv2-licensed source code for wolfSSL/CTaoCrypt directly from our download page and try it out for yourself.

yaSSL Embedded Web Server 1.0 is Now Available

The third release of the yaSSL Embedded Web Server is now available for download!  Changes in this release include bug fixes, updated wolfSSL support, iOS (Apple TV) build support, better Windows build support, CGI and SSI extension pattern matching and more.

The yaSSL Embedded Web Server is focused on being small, fast, and embeddable.  Features include CGI, SSI, IP restrictions, access and error log support, and SSL among others.  The wolfSSL embedded SSL library can be used to easily secure ports with SSL/TLS up to TLS 1.2, giving you a secure connection while maintaining small size and fast speed.  

If you have any questions, or would like to learn more about the yaSSL Embedded Web Server and how it can help your project, please contact

wolfSSL 2.3.0 is Now Available

Version 2.3.0 of the wolfSSL embedded SSL/TLS library has been released and is now available for download.  This release contains bug fixes and new features. Changes include the following (with details and comments for each listed below):

– AES-GCM crypto and cipher suites
– “make test” cipher suite checks
– Subject AltName processing
– Command line support for client/server examples
– Sniffer SessionTicket support
– SHA-384 cipher suites
– Verify cipher suite validity when user overrides
– CRL directory monitoring
– DTLS Cookie support, reliability coming soon


The addition of AES-GCM (Galois/Counter Mode) cryptography and cipher suites brings the wolfSSL embedded SSL library one step away from being NSA Suite B compliant. The one missing element is ECC – which wolfSSL will be getting in September 2012.

wolfSSL 2.3.0 offers four different implementations of AES-GCM balancing speed versus memory consumption. If available, wolfSSL will use 64-bit or 32-bit math. For embedded applications, there is a speedy 8-bit version that uses RAM-based lookup tables (8KB per session) which is speed comparable to the 64-bit version and a slower 8-bit version that doesn`t take up any additional RAM. To enable AES with GCM in wolfSSL, configure the build with the option “–enable-aesgcm”. The configure option may be modified with the options “=word32”, “=table”, or “=small”, i.e. “–enable-aesgcm=table”.

“make test” Cipher Suite Checks

With the last few releases of wolfSSL, we’ve been working on enhancing wolfSSL’s default test cases which are executed when “make test” is issued from the wolfSSL root directory. With this release, we have added test cases for wolfSSL’s ciphers suites. The cipher suite checks iterate through wolfSSL’s SSL 3.0, TLS 1.0, 1.1, and 1.2 cipher suites (as defined in the /tests/test.conf file), verifying that each suite works correctly. When running “make test” you will now see output similar to the following for each cipher suite tested:

# server SSLv3 RC4-SHA
# client SSLv3 RC4-SHA
trying server command line[1]: SuiteTest -v 0 -l RC4-SHA
trying client command line[1]: SuiteTest -v 0 -l RC4-SHA
Client message: hello cyassl!
Server response: I hear you fa shizzle!

Subject AltName Processing

An X.509 certificate may contain a Subject Alternative Name, or “subjectAltName” extension which allows identities to be bound to the subject of the certificate. These names might be included in addition to the existing name in the Subject field of an X.509 certificate, or they may included in place of the standard Subject field of the certificate. Subject Alternative Names may take a variety of formats including an email address, DNS name, IP address, or a URI. This extension is defined in Section of RFC 5280 (

With this release, wolfSSL now processes Subject Alternative Names in certificates. wolfSSL has a new API function, wolfSSL_X509_get_next_altname() which allows retrieval of the subjectAltNames that have been processed.

Command Line Support for client/server Examples

The wolfSSL example client and server can now be run from the command line with a number of different options. These options allow users to select the Host, Port, SSL version, cipher list, certificate file, key file, CA file, toggle DTLS and pre shared keys, and more. To see the available options, run either ./examples/client/client or ./examples/server/server with the “-?” option:

./examples/client/client -?

The available options will be listed, similar to:

client 2.3.0 NOTE: All files relative to wolfSSL home dir
-? Help, print this usage
-h Host to connect to, default
-p Port to connect on, default 11111
-v SSL version [0-3], SSLv3(0) – TLS1.2(3)), default 3
-l Cipher list
-c Certificate file, default ./certs/client-cert.pem
-k Key file, default ./certs/client-key.pem
-A Certificate Authority file, default ./certs/ca-cert.pem
-b Benchmark connections and print stats
-s Use pre Shared keys
-d Disable peer checks
-g Send server HTTP GET
-m Match domain name in cert

Sniffer SessionTicket Support

wolfSSL’s Sniffer (or Inspection) functionality has been made more robust by the addition of support for TLS Session Tickets. The SessionTicket TLS extension is defined in RFC 5077 ( This extension enables a TLS server to resume sessions without storing per-client session information on the server side. The server encapsulates the current session state for a specific client into a ticket and forwards it to the client. That client is then able to resume a session if needed by using the previously-obtained ticket from the server.

SHA-384 Cipher Suites

With the addition of GCM support to wolfSSL, we have also added a number of SHA-384 cipher suites. New SHA-384 suites include:


Verify Cipher Suite Validity when User Overrides

wolfSSL 2.3.0 now checks to make sure that certificates and keys loaded into wolfSSL are valid for specified cipher suites chosen by the user. This added check enhances wolfSSL’s robustness and will prevent errors some users see when hand-picking cipher suites to use while not having all the correct functionality built into wolfSSL.

CRL Directory Monitoring

As you may know, we added initial support for CRL (Certificate Revocation List) with the release of wolfSSL 2.2.0 in May of this year. With this 2.3.0 release, we have added the ability to have wolfSSL actively monitor a specific CRL directory. Example usage can be seen in the wolfSSL example server (./examples/server/server.c) inside of the HAVE_CRL defines:

wolfSSL_EnableCRL(ssl, 0);
wolfSSL_SetCRL_Cb(ssl, CRL_CallBack);

DTLS Cookie Support

wolfSSL has had DTLS support for quite some time, but we’re currently working on making it more functional and robust. With this release, wolfSSL’s DTLS implementation now supports cookies. Cookies are used in DTLS to prevent denial of service attacks. As stated in section 4.2.1 of RFC 4347 (

“Datagram security protocols are extremely susceptible to a variety of denial of service (DoS) attacks. Two attacks are of particular concern:

• An attacker can consume excessive resources on the server by transmitting a series of handshake initiation requests, causing the server to allocate state and potentially to perform expensive cryptographic operations.

• An attacker can use the server as an amplifier by sending connection initiation messages with a forged source of the victim. The server then sends its next message (in DTLS, a Certificate message, which can be quite large) to the victim machine, thus flooding it.

In order to counter both of these attacks, DTLS borrows the stateless cookie technique used by Photuris ( and IKE ( When the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message. This message contains a stateless cookie generated using the technique of Photuris. The client MUST retransmit the ClientHello with the cookie added. The server then verifies the cookie and proceeds with the handshake only if it is valid. This mechanism forces the attacker/client to be able to receive the cookie, which makes DoS attacks with spoofed IP addresses difficult. “

We’re currently working on adding reliability to our DTLS implementation. This should be rolling out in the near future, so keep an eye on our blog for more news!

To download the open source, GPLv2-licensed version of wolfSSL 2.3.0, please visit our Download Page.  If you have any questions or comments or would like more information on commercial versions of wolfSSL, please contact us at

For build instructions, a full feature list, API reference, and more, please see the wolfSSL Manual.

Posts navigation

1 2 3 81 82 83 84 85 86 87 106 107 108

Weekly updates


Latest Tweets