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.
With the 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 firstname.lastname@example.org.
wolfSSL can now be used to replace OpenSSL in WebSocket++!
WebSocket++ is a header only C++ library that implements RFC6455 The WebSocket Protocol. It allows integrating WebSocket client and server functionality into C++ programs and uses interchangeable network transport modules including one based on raw char buffers, one based on C++ iostreams, and one based on Asio (either via Boost or standalone). End users can write additional transport policies to support other networking or event libraries as needed.
Since wolfSSL is compatible with Asio and Boost.Asio (see Asio blog post), it can be used to replace OpenSSL for cryptographic and TLS purposes when building WebSocket++ with Asio or Boost.Asio.
To build WebSocket++, enter the following commands from the root directory of your WebSocket++ download.
$ cmake . $ make $ sudo make install
Now install the wolfSSL compatible versions of Asio or Boost.Asio and build it with wolfSSL (see blog post).
You should now be able to compile and execute programs with WebSocket++ and wolfSSL. Just make sure to link all of the necessary libraries (asio and wolfSSL) and their include paths when compiling.
To run the WebSocket++ unit tests with wolfSSL you will need the wolfSSL modified version of WebSocket++. Please contact email@example.com if you want us to send you the source code.
To run the Ctest tests, execute the following commands from the root directory of the wolfSSL modified WebSocket++ download.
$ cmake -DBUILD_TESTS=ON -DBUILD_EXAMPLES=ON -DWOLFSSL=/path/to/wolfSSL/install . $ ctest .
If you want to run more thorough tests with wolfSSL and WebSocket++ you will need to download and install scons. You should then be able to execute the scons tests with the following commands.
$ export BOOST_ROOT=$WORKSPACE/boost_1_67_0 $ export WOLFSSL_PATH=/path/to/wolfSSL/install $ scons $ scons test
For more information or help with getting WebSocket++ and wolfSSL into your project, please contact us at firstname.lastname@example.org.
wolfSSL is at NXP Tech Days's Seattle event 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 NXP Tech Days will be for Seattle:
Venue: Meydenbauer Center, Bellevue, WA 98004
When: May 7th, 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 email@example.com.
More information about NXP Tech Days and the Seattle Agenda can be found here: https://www.nxp.com/support/training-events/nxp-technology-days:NXP-TECH-DAYS.
The National Institute of Standards and Technology (NIST) has completed the validation of the wolfCrypt module version 4 for an updated Federal Information and Processing Standards (FIPS) 140-2 certificate in addition to its previous FIPS 140-2 certificate. This new certificate includes updated and more secure algorithms added to the wolfCrypt module's boundary, some of which are listed further below.
FIPS 140-2 is a government standard that specifies a software module is compatible and allowed to be used in government systems. This includes such areas as drone software, government databases, and other high-security/high-power uses.
The new FIPS 140-2 validation has certificate #3389. The Operating Environments (OEs) tested are Ubuntu Linux (16.04) and Windows 10 on Intel Core i5 processors. Full details about the OEs can be found on the CSRC certificate page. Additionally, the certificate also includes the following algorithms: AES (CBC, GCM, CTR, ECB), CVL, Hash DRBG, DSA, DHE, ECDSA (key generation, sign, verify), HMAC, RSA (key generation, sign, verify), SHA-3, SHA-2, SHA-1, and Triple-DES.
For more information about wolfSSL, wolfCrypt, or our FIPS 140-2 validations, please view our resources below.
- wolfSSL FIPS page: https://www.wolfssl.com/license/fips/
- wolfSSL product page: https://www.wolfssl.com/products/wolfssl/
- wolfCrypt product page: https://www.wolfssl.com/products/wolfcrypt/
Other information can be obtained, or questions can also be answered by contacting firstname.lastname@example.org.
wolfSSL will also be attending ICMC this year! More information about ICMC can be found here: https://icmconference.org
Some interesting results were found when comparing the throughput of TLS 1.2 and TLS 1.3 using an assembly optimized wolfSSL – some good, some bad. This is the last of the 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. There are differences in the way the data is encrypted in TLS 1.2 and 1.3. For some algorithms this makes a noticeable difference.
TLS 1.2 encrypts the plaintext of the message and generates an authentication code on the encrypted data plus additional_data which includes: a 64-bit sequence number, 1 byte content type, 2 byte version and 2 byte length. This is a total of 13 extra bytes in additional_data.
TLS 1.3 encrypts the plaintext of the message plus one byte for the real record type and generates an authentication code on the encrypted data plus the record header of 5 bytes.
For AES-GCM cipher suites the throughput was observed to be slightly increased with the Intel x86 64-bit optimized assembly code. This is due to the number of bytes passed in as additional authentication data (AAD). The AAD bytes are processed separately before encryption and decryption and it turned out processing 5 bytes was faster than 13. The extra byte on the end of the encrypted data did not have a significant impact.
For Chacha20-Poly1305 the different size of data passed in as AAD has no significant impact as the data is placed into a 16 byte block and padded before being processed. But, the extra byte at the end of the plaintext did impact the Chacha20 and Poly1305 performance. For Poly1305, the extra byte resulted in an extra 16 byte block being processed. In total this had about a 3-5% impact on throughput with the Intel x86 64-bit optimized assembly code.
TLS 1.3 has better throughput when using AES-GCM and is another reason to change. For maximum throughput consider sending one less than the maximum plaintext size, by default 16384 bytes, in an application data message. This will have a positive impact for both AES-GCM and Chacha20-Poly1305 cipher suites.
Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
Part 3 (TLS 1.3 Performance – Pre-Shared Key (PSK))
Part 4 (TLS 1.3 Performance – Server Pre-Generation)
Part 5 (TLS 1.3 Performance – Client-Server Authentication)
The wolfSSL embedded SSL/TLS library supports running on several Renesas platforms and has support for both the Renesas CS+ and e2 studio development environments. To make it easy to get started with wolfSSL, wolfSSL offers several example CS+ and e2 studio projects which can be run on a Starter Kit or Alpha Project board. The example programs include SSL/TLS server/client example projects running on top of uITRON and TINET (their network layer API). Additionally, there is also a wolfCrypt test (benchmark application) example project included as well that allows the user to see the performance of wolfCrypt's implementations on the desired platform.
Renesas CS+ (formerly CubeSuite+) is an integrated development environment that provides simplicity, security and ease of use in developing software through iterative cycles of editing, building, and debugging. Renesas e2 studio is a development environment based on the popular Eclipse CDT (C/C++ Development Tooling), which includes build (editor, compiler and linker control), as well as debug interfaces. More information about Renesas and wolfSSL can be found here: https://www.wolfssl.com/docs/wolfssl-renesas-support/.
For more information, please contact email@example.com.
TLS 1.3 has some significant changes from TLS 1.2 in the ordering of handshake messages and this impacts performance. This is the fifth 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 how the changes to certificate based client-server authentication in TLS 1.3 adversely affects performance.
Let’s start with a look at the TLS 1.2 full handshake performing client-server authentication with certificates below.
A TLS 1.3 full handshake (without HelloRetryRequest) performing client and server authentication with certificates is given 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 improves performance on high latency networks but there is a downside. What is clear in the diagram is when messages are sent but not how and when handshake messages are processed.
The table below restates the TLS 1.2 handshake, but includes the processing of messages and the major cryptographic operations that are performed. Operations are on the same line if the operations are performed at the same time relative to network latency.
The server produces a KeyShare, sends the ServerHello, and then quickly sends the EncryptedExtensions, CertificateRequest and Certificate messages. The CertificateVerify takes a while to produce and the Finished message is quick. The client takes a while to process the KeyShare, quickly process the EncryptedExtensions and CertificateRequest messages, and spends a long time performing certificate chain verification. The CertificateVerify will typically arrive during the chain verification and then the client processes the rest of the messages synchronously. As a result, there is little overlap.
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 2 x Verify. For ECDSA, where Verify is slower than Key Gen plus Sign: 1 x Secret Gen and 3 x Verify.
The table below restates 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 using RSA certificates is dependent on: 2 x Key Gen, 1 x Sercret Gen, 2 x Sign. Therefore a Secret Gen and 2 x Verify in TLS 1.2 are replaced with a Sign. Using ECDSA a handshake is dependent on: 2 x Key Gen, 1 x Sercret Gen and 4 x Verify. Therefore, a Secret Gen and Sign in TLS 1.2 is replaced by 2 x Verify.
This means that for low latency networks TLS 1.3 can be slightly slower or about as fast as TLS 1.2. The only practical mitigation for ECC certificates is to minimize the amount of work performed in chain verification. Having the server certificate stored on the client and/or the client certificate stored on the server will improve TLS 1.3 performance but at the risk of lower security.
The next blog will be the final one in this series and will discuss difference in throughput between TLS 1.2 and 1.3.
The wolfSSL embedded SSL/TLS library features many different ports, including one for Apache Mynewt. Apache Mynewt is a Real-Time Operating System (RTOS) that is used to build, deploy, and securely manage billions of devices. It is designed for IoT devices that have limited memory and storage and need to run for a long time with minimal power consumption. wolfSSL's port for Mynewt uses Mynewt's raw socket interface "mnsocket" to send and receive data through an SSL/TLS connection.
The wolfSSL port for Apache Mynewt is the ideal solution for security in your embedded IoT device. Apache Mynewt is an RTOS created with resource constrained devices in mind, and wolfSSL is an embedded SSL/TLS library created with speed, strength, portability, and low footprint size in mind. The combination of wolfSSL and Apache Mynewt results in a powerful security solution.
For more information, please contact firstname.lastname@example.org.
wolfSSL also provides support for TLS 1.3, the most recent version of the TLS protocol!
authored by Daniel Stenberg - original post: https://gist.github.com/bagder/5970df691b7cdef65e95d3d48ebd8659
You most probably already know why you would use curl and if I'm right, you're also a fan of using the right tool for the job. But do you know why others use curl and why they switch from other solutions to relying on curl for their current and future data transfers? Let me tell you the top reasons I'm told by users.
Logging and exact error handling
What exactly happened in the transfer and why are terribly important questions to some users, and with curl you have the tools to figure that out and also be sure that curl either returns failure or the command worked. This clear and binary distinction is important to users for whom that single file every transfer is important. For example, some of the largest and most well-known banks in the world use curl in their back-ends where each file transfer can mean a transfer of extremely large sums of money.
A few years ago I helped a money transaction service switch to curl to get that exact line in the sand figured out. To know exactly and with certainty if money had been transferred - or not - for a given operation. Vital for their business.
curl does not have the browsers' lenient approach of "anything goes as long as we get something to show" when it comes to the Internet protocols.
curl's verbose output options allow users to see exactly what curl sends and receives in a quick and non-complicated way. This is invaluable for developers to figure out what's happening and what's wrong, in either end involved in the data transfer.
curl's verbose options allows developers to see all sent and received data even when encryption is used. And if that is not enough, it's SSLKEYLOGFILE support allows you to take it to the next level when you need to.
Same behavior over time
Users sometimes upgrade their curl installations after several years of not having done so. Bumping a software's version after several years and many releases, any software really, can be a bit of a journey and adventure many times as things have changed, behavior is different and things that previously worked no longer do etc.
With curl however, you can upgrade to a version that is a decade newer, with lots of new fancy features and old crummy bugs fixed, only to see that everything that used to work back in the day still works - the same way. With curl, you can be sure that there's an enormous focus on maintaining old functionality when going forward.
Present on all platforms
The fact that curl is highly portable, our users can have curl and use curl on just about any platform you can think of and use it with the same options and behaviors across them all. Learn curl on one platform, then continue to use it the same way on the next system. Platforms and their individual popularity vary over time and we enjoy to allow users to pick the ones they like - and you can be sure that curl will run on them all.
When doing the occasional file transfer every once in a while, raw transfer performance doesn't matter much. Most of the time will then just be waiting on network anyway. You can easily get away with your Python and java frameworks' multiple levels of overhead and excessive memory consumption.
Users who scan the Internet or otherwise perform many thousands of transfers per second from a large number of threads and machines realize that they need fewer machines that spend less CPU time if they build their file transfer solutions on top of curl. In curl we have a focus on only doing what's required and it's a lean and trimmed solution with a well-documented API built purely for Internet data transfers.
The features you want
The author of a banking application recently explained for us that one of the top reasons why they switched to using curl for doing their Internet data transfers, is curl's ability to keep the file name from the URL.
curl is a feature-packed tool and library that most likely already support the protocols you need and provide the power features you want. With a healthy amount of "extension points" where you can extend it or hook in your custom extra solution.
Support and documentation
No other tool or library for internet transfers have even close to the same amount of documentation, examples available on the net, existing user base that can help out and friendly users to support you when you run into issues. Ask questions on the mailing lists, post a bug on the bug tracker or even show your non-working code on stackoverflow to further your project.
curl is really the only Internet transfer option available to get something that's old and battle-proven proven by the giants of the industry, that is trustworthy, high-performing and yet for which you can also buy commercial support for, today.
wolfSSL provides the wolfSSL embedded SSL/TLS library, which is a fast, secure, and highly portable implementation of the SSL/TLS protocols. As part of being highly portable, the wolfSSL library is frequently being ported to various other software modules and devices for users to easily implement wolfSSL's features. One of these more recent ports that wolfSSL has is a port to the Apache HTTP server project coming out soon!
Apache is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows. Its goal is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. Using wolfSSL with Apache will also allow users to implement some of the other high profile features offered by wolfSSL, such as TLS 1.3 support, FIPS 140-2 validated code, and dual-licensed commercial support. wolfSSL also provides an OpenSSL compatibility layer, which can be easily used to switch from using OpenSSL's security to using wolfSSL's security.
For more information, please contact email@example.com.
- July 2019 (2)
- June 2019 (13)
- May 2019 (35)
- April 2019 (32)
- 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 (5)
- 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)