RECENT BLOG 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.
Significant changes from TLS 1.2 have been made in TLS 1.3 that are targeted at performance. This is the second part of six blogs discussing the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. This blog discusses the performance differences with regard to full handshake with server authentication using certificates.
Let’s start with a look at the TLS 1.2 full handshake performing server-only authentication with certificates below.
A TLS 1.3 full handshake (without HelloRetryRequest) performing server-only authentication with certificates is below.
Notice that there is one less round trip until Application Data can be sent in TLS 1.3 as compared to TLS 1.2. This significantly improves performance especially on high latency networks. But, there is another source of performance improvement arising from the ordering of the handshake messages and when lengthy cryptographic operations are performed.
In the TLS handshake, the server waits on the ClientHello and then sends handshake messages as it produces them in separate packets. When packets are sent is dependent on the amount of processing required to produce the data. For example, to copy a chain of certificates into the Certificate messages is quick, while generating a TLS 1.2 ServerKeyExchange message is slow as it requires multiple public key operations.
The client receives the messages at various time deltas and also requires differing amounts of processing. For example, the Certificate message is likely to require at least one signature verification operation on the leaf certificate. This asymmetric processing of messages means that some handshake messages will be processed on arrival and some will have to wait for processing of previous messages to be completed.
The table below restates the TLS 1.2 handshake but includes processing of messages and the major cryptographic operations that are performed. Operations are on the same line if the they are performed at the same time relative to network latency.
From this we can see that for RSA, where Verify is very fast relative to Sign, a TLS 1.2 handshake is dependent on: 2 x Key Gen, 2 x Secret Gen, 1 x Sign and 1 x Verify. For ECDSA, where Verify is slower than Key Gen plus Sign: 1 x Key Gen, 2 x Secret Gen and 2 x Verify.
The table below is a restating of the TLS 1.3 handshake including processing of message and the major cryptographic operations.
From this we can see that a TLS 1.3 handshake with RSA, where Verify is a lot faster than Sign, is dependent on: 2 x Key Gen, 1 x Secret Gen, 1 x Sign. Therefore, a Secret Gen and Verify in TLS 1.2 are saved. For ECDSA, where Verify is a lot slower than Sign, the TLS 1.3 handshake is dependent on: 2 x Key Gen, 1 x Secret Gen, 2 x Verify. Therefore, a Secret Gen in TLS 1.2 is traded for a faster Key Gen.
Running both the client and server on the same computer results in about a 15% improvement in the performance of ephemeral DH with RSA handshakes – mostly due to the parallel operations. With ephemeral ECDH and RSA there is about a 6% improvement, and with ECDHE and ECDSA there is about a 7% improvement – mostly due to the saving in round-trips.
These improvements come for free when using TLS 1.3 without the HelloRetryRequest. The next blog will discuss handshakes using pre-shared keys.
For more information regarding wolfSSL and the TLS 1.3 full handshake, please contact email@example.com.
wolfSSL is at wolfSSL at NXP Tech Days Minneapolis this year! NXP Technology Days is a deep-dive, technical training program for engineers designing solutions with embedded technology. This one-day event offers hands-on workshops and technical lectures over multiple markets enabling attendees to customize a schedule that is most relevant to their training needs.
Where wolfSSL will be located for this Tech Days:
Venue: Doubletree by Hilton Minneapolis Park Place
When: April 16, 2019
Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL team, or to get some free stickers and swag!
For more information about wolfSSL, its products, or future events, please contact firstname.lastname@example.org.
More information about NXP Tech Days can be found here: https://www.nxp.com/support/training-events/nxp-technology-days:NXP-TECH-DAYS
TLS 1.3 is the latest version of the SSL/TLS specification. There are significant changes to messages and the message flow. These changes are targeted at security and performance.
The first performance difference to note is a degradation. In TLS 1.2 performing a resumption handshake is very quick. This comes at a security cost though. Each time a client resumes a session, the same session ID is used and the same master secret is used. Therefore, if the master secret is compromised then all resumed sessions are revealed. Also, TLS 1.2 resumption is stateful and can have performance issues in a multi-server architecture.
TLS 1.3 only uses session tickets to resume a session. This mechanism has the client send an opaque session ticket to the server that contains a server encrypted version of all the information required to resume the session. Once again the same master secret is used across handshakes but the default behavior is to perform a key exchange. A unique, shared secret is generated and combined with the master secret when calculating keys and IVs. This mechanism then provides forward secrecy.
The performance trade-off here is that using a session ticket requires decryption of the session ticket. Also, TLS 1.3 performs more encryption/decryption and hashing operations in the handshake anyway. Therefore, when running a client and server on the same computer, a TLS 1.3 handshake is more than 20% slower. On a high latency network, these will not be noticeable as symmetric cipher and digest algorithms are the fastest of operations.
But also consider the default behaviour that results in a key exchange. DH key and secret generation are some of the most expensive operations and the handshake, again running both client and server on the same computer, using 2048-bit DH parameters can take 13 times as long as TLS 1.2 resumption. ECDH can be used instead and is at least twice as slow when using a highly optimised implementation.
There is no way in TLS 1.3 to avoid this performance degradation and resumption has the fastest handshake performance. Using optimised ECDH will give you the best performance and better security. There is a way to improve the resumption performance, in some cases, which will be discussed in a future blog in this series.
For more information about wolfSSL and TLS 1.3 session ticket resumption, please contact email@example.com.
People have been asking if wolfSSL is vulnerable to the ’Selfie’ attack (https://eprint.iacr.org/2019/347). We are glad to say that we follow all the recommendations made by the authors. First, though, an explanation of the attack.
The attack targets the use of Pre-Shared Keys (PSKs) with TLS 1.3 though TLS 1.2 is also vulnerable. There are very specific use cases that are affected. When a group of computers want to connect to each other then sharing a PSK is a simple way to set things up. Membership of the group is based on the knowledge of the PSK. This means that certificate authentication is not used.
The attack scenario is when a new computer comes into the network that can intercept or Man-in-the-Middle (MitM) the communications between computers. When a computer, let’s call it Alice, acting as a client sends a TLS ClientHello, the MitM, which we’ll call Eve, reflects the message back in a new connection to Alice. Alice acting as a server sees a new TLS ClientHello and in parallel responds with the first round of messages. These messages are sent back by Eve to the client on Alice. Alice as a client uses the messages to establish a connection and sends a response. Eve uses the response to respond to Alice the server and so on and a secure connection is established.
Because everyone is using the same PSK for client and server connections, Alice does not notice anything wrong! Now that a secure connection has been established, which Eve cannot decrypt, it can be hard to see what the issue would be. The attack comes when a message like ‘Delete your copy of this file, I have a copy’ is sent. Eve reflects the message back and Alice decides that the she doesn’t have to keep a copy after all and deletes it.
The paper lists a number of scenarios that may be vulnerable:
- Content Delivery Networks (CDNs) - poisoning caches.
- P2P Networks.
- WiFi networks that rely on PSKs for the entire network.
- Leader-election and consensus protocols.
Mitigations and Recommendations
One way to prevent this attack is to use the Server Name indicator (SNI) extension. This way Alice recognises she didn’t connect to the computer she wanted to but to herself.
The recommendations of the paper are:
- Don’t share PSKs amongst a group of computers unless certificates are used initially to establish identity. This goes against the PSK use case!
- If you must use a shared PSK without certificates, then use the SNI extension.
- TLS toolkits should either not implement PSK or not have it configured by default.
By default in wolfSSL, PSKs are not enabled but are available for use when you need it. wolfSSL also implements the SNI extension and we encourage you to use it.
For more information about the wolfSSL library, please contact firstname.lastname@example.org.
With the recent release of wolfSSL 4.0.0, the wolfSSL team has also released a new product: the wolfSSL FIPS Ready library. This product features new, state of the art concepts and technology. In a single sentence, wolfSSL FIPS Ready is a testable and free to download open source embedded SSL/TLS library with support for FIPS validation, with FIPS enabled cryptography layer code included in the wolfSSL source tree. To further elaborate on what FIPS Ready really means, you do not get a FIPS certificate and you are not FIPS approved. FIPS Ready means that you have included the FIPS code into your build and that you are operating according to the FIPS enforced best practices of default entry point, and Power On Self Test (POST).
FIPS validation is a government certification for cryptographic modules that states that the module in question has undergone thorough and rigorous testing to be certified. FIPS validation specifies that a software/encryption module is able to be used within or alongside government systems. The most recent FIPS specification is 140-2, with various levels of security offered (1-5). Currently, wolfCrypt has FIPS 140-2 validation with certificates #2425 and #3389. When trying to get software modules FIPS validated, this is often a costly and time-consuming effort and as such causes the FIPS validated modules to have high price tags.
Since the majority of wolfSSL products use the wolfCrypt encryption engine, this also means that if wolfSSH, wolfMQTT (with TLS support), wolfBoot, and other wolfSSL products in place can be tested FIPS validated code with their software before committing.
wolfSSL FIPS Ready can be downloaded from the wolfSSL download page, here: https://www.wolfssl.com/download/
For more information about wolfSSL and its FIPS Ready initiative, please contact email@example.com.
Recently, we announced that there was support for JSSE in the works at wolfSSL. That project is currently nearing completion, and wolfSSL will soon be happy to announce its support for providing JSSE included with the wolfSSL-JNI library!
Java Secure Sockets Extension (JSSE) is a way for Java applications to utilize the SSL and TLS protocols through a standardized Java API using pluggable “providers” underneath - which is where wolfSSL will come in to place. wolfSSL provides SSL and TLS support up to the most recent versions of these protocols, and also provides high speed and strength encryption as well. Other beneficial features include potential use of wolfCrypt FIPS, low footprint, high portability, and more!
Stay tuned for the release of wolfSSL's support for providing JSSE! For more information, please contact firstname.lastname@example.org.
With the recent release of wolfSSL 4.0.0, the wolfSSL embedded SSL/TLS library comes with many new features and improved functionality. Among these features is the addition of a port to the Zephyr Project - a scalable real-time operating system (RTOS) supporting multiple hardware architectures, optimized for resource constrained devices, and built with safety and security in mind.
wolfSSL's Zephyr port comes with multiple test and example applications, such as the wolfCrypt unit tests, wolfSSL TLS with sockets, and wolfSSL TLS with threads example applications. This Zephyr port allows for its users to easily implement lightweight, high-speed and strong encryption for secure data transfer on their devices. As both Zephyr and wolfSSL are targeted for resource-constrained and embedded devices, this combination only makes sense.
More information about the 4.0.0 release of wolfSSL can be found in our blog post here: https://www.wolfssl.com/wolfssl-4-0-0-now-available/
For other information or queries, please contact email@example.com.
Are you a user of the ESP-IDF(Espressif IoT Development Framework)? If so, you will be happy to know that wolfSSL recently added support and example projects to the wolfSSL embedded SSL/TLS library for ESP-IDF.
ESP-IDF is intended for rapidly developing Internet-of-Things (IoT) applications, with Wi-Fi, Bluetooth, power management and several other system features.
The ESP-IDF “Get Started” document can be found here:
In order to use wolfSSL under ESP-IDF, you need to deploy wolfSSL source files into the IDE. Please see the README.md placed in the “IDE/Espressif/ESP-IDF/” directory of wolfSSL source tree. In addition to that, example projects including TLS server/client, wolfCrypt test and benchmark are also provided. For building these examples, please see each README.md in example projects directories. When working with ESP-IDF, wolfSSL worked with the ESP32-WROOM-32 device.
wolfSSL also has a page that elaborates upon the use of Espressif with wolfSSL and the Espressif hardware devices, located here: https://www.wolfssl.com/docs/espressif/
Our wolfSSL master branch can be cloned here:
The README.md can be found here:
Additional examples for wolfSSL TLS Client/Server and wolfCrypt test/benchmark applications can be found here:
This support is currently located in our GitHub master branch, and will roll into the next stable release of wolfSSL as well. For any questions or help getting wolfSSL up and running on your ESP-IDF environment, please contact us at firstname.lastname@example.org.
wolfSSL's embedded SSL/TLS library provides support for many different features, such as TLS 1.3, a FIPS 140-2 validation, and even support for SSL/TLS using less traditional I/O. In this context, “less traditional I/O” means running SSL/TLS over something besides TCP/IP or UDP - for example Bluetooth, a serial connection, memory buffers, or a proprietary transfer protocol. In embedded projects, we know it can be common.
The wolfSSL embedded SSL/TLS library provides a mechanism to plug in your own application-specific I/O routines. By default, the library calls a BSD socket API, with functions that call the system’s recv() and send() using a file descriptor that has been cached with wolfSSL_set_fd().
The prototypes for the I/O callback functions are:
typedef int (*CallbackIORecv)(WOLFSSL *ssl, char *buf, int sz, void *ctx); typedef int (*CallbackIOSend)(WOLFSSL *ssl, char *buf, int sz, void *ctx);
In the default case, the network socket file descriptor is passed to the I/O callback through the “ctx” parameter. The “ssl” parameter is a pointer to the current wolfSSL session, giving callbacks access to session-level details if needed.
In the receive case, “buf” points to the buffer where incoming ciphertext should be copied for wolfSSL to decrypt and “sz” is the size of the buffer. Callbacks should copy “sz” bytes into “buf”, or the number of bytes available. In the send case, “buf” points to the buffer where wolfSSL has written ciphertext to be sent and “sz” is the size of that buffer. Callbacks should send “sz” bytes from “buf” across their transport medium. In either case the number of bytes written or read should be returned, or alternatively an applicable error code.
To register your own I/O callbacks with the wolfSSL Context (WOLFSSL_CTX) for your application, use the functions wolfSSL_SetIORecv() and wolfSSL_SetIOSend().
wolfSSL_SetIORecv(ctx, myCBIORecv); wolfSSL_SetIOSend(ctx, myCBIOSend);
An example use case for alternative I/O would be to have a server with a datagram socket which receives data from multiple clients or processes TLS through STDIN and STDOUT. In this case you would have four buffers:
cipher-receive encrypted data received from peer cipher-send encrypted data to send to peer clear-receive clear data received from wolfSSL clear-send clear data passed to wolfSSL
Pointers to these buffers, values for their sizes, and read and write positions might be placed into a user-defined structure. A pointer to this structure could then be cached in the wolfSSL session with the functions wolfSSL_SetIOReadCtx() and wolfSSL_SetIOWriteCtx().
wolfSSL_SetIOReadCtx(ssl, buffer_data); wolfSSL_SetIOWriteCtx(ssl, buffer_data);
The application would receive a block of ciphertext into the buffer “cipher-receive”. Next the application would call wolfSSL_read(ssl, buffer_data->clear_receive), causing wolfSSL to call the registered receive callback. That receive callback will be given a buffer, the size of the buffer, and the ctx, which has the “cipher-receive” buffer. The callback may be called many times internally for one call to wolfSSL_read(). If the “cipher-receive” buffer is empty, the callback should return WOLFSSL_CBIO_ERR_WANT_READ, otherwise it should return the number of bytes copied into “buf”.
When the library wants to send data, during handshaking or when wolfSSL_send() is called with plaintext, the library will call the registered send callback. The callback is given a buffer full of encrypted data, and the length of the encrypted data. In this example, the callback would copy this cipher text into “cipher-send” and return the number of bytes copied. If the “cipher-send” buffer isn’t big enough, the callback should return WOLFSSL_CBIO_ERR_WANT_WRITE.
If you are interested in looking over an example of using the wolfSSL I/O abstraction layer, we have an example client/server application at the following link that does TLS using files as the transport medium: https://github.com/wolfSSL/wolfssl-examples/tree/master/custom-io-callbacks
If you have questions about using wolfSSL’s custom I/O callback layer, please contact us at email@example.com.
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)
- 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.
- April 2019 (20)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (11)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (11)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (6)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (6)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (9)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)