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.
wolfSSL is proud to announce release version 3.15.3 of the wolfSSL embedded TLS library. This release contains bug fixes and new features, which include:
- ECDSA blinding added for hardening against side channel attacks
- Fix for OpenSSL compatibility layer build with no server (NO_WOLFSSL_SERVER) and no client (NO_WOLFSSL_CLIENT) defined
- Intel assembly instructions support for compatible AMD processors
- wolfCrypt port for Mentor Graphics Nucleus RTOS
- Fix added for MatchDomainName() with additional tests added
- Fixes for building with ‘WOLFSSL_ATECC508A’ defined
- Fix for verifying a PKCS7 files in BER format with indefinite size
This release of wolfSSL fixes 2 security vulnerability fixes:
Medium level fix for PRIME + PROBE attack combined with a variant of Lucky 13. Constant time hardening was done to avoid potential cache-based side channel attacks when verifying the MAC on a TLS packet. CBC cipher suites are susceptible on systems where an attacker could gain access and run a parallel program for inspecting caching. Only wolfSSL users that are using TLS/DTLS CBC cipher suites need to update. Users that have only AEAD and stream cipher suites set, or have built with WOLFSSL_MAX_STRENGTH (--enable-maxstrength), are not vulnerable. Thanks to Eyal Ronen, Kenny Paterson, and Adi Shamir for the report.
Medium level fix for a ECDSA side channel attack. wolfSSL is one of over a dozen vendors mentioned in the recent Technical Advisory “ROHNP” by author Ryan Keegan. Only wolfSSL users with long term ECDSA private keys using our fastmath or normal math libraries on systems where attackers can get access to the machine using the ECDSA key need to update. An attacker gaining access to the system could mount a memory cache side channel attack that could recover the key within a few thousand signatures. wolfSSL users that are not using ECDSA private keys, that are using the single precision math library, or that are using ECDSA offloading do not need to update. (blog with more information: https://www.wolfssl.com/wolfssl-and-rohnp/)
wolfSSL will be attending Sensors Midwest 2018 next week in Rosemont, IL. Stop by to talk with engineering manager Chris Conlon and sales & marketing director Christin Casperson.
Sensors Midwest will be held on October 16th and 17th, at the Donald E. Stephens Convention Center, and wolfSSL will be attending on both of these days.
Additionally, Chris Conlon will be giving a speech titled "An Overview of TLS 1.3" on Tuesday, October 16th, from 10:10am to 11:00am.
Stop by booth #212 to have questions about wolfSSL/licensing answered in person, to learn more about the benefits of a TLS 1.3 implementation written in C combined with FIPS, to hear Chris's speech, or to pick up some nifty stickers. We look forward to seeing you there!
wolfSSL will be attending at ARM TechCon 2018 next week, in San Jose, CA. Stop by to talk with business director Rich Kelm, software engineer Tesfa Mael, and intern Rylie DeGarmo.
ARM TechCon 2018 will be held from October 16th to October 18th, at the San Jose Convention Center (directions), and wolfSSL will be attending on October 17th and 18th.
Stop by booth #1026 to have questions about wolfSSL/licensing answered in person, to learn more about the benefits of an all C TLS 1.3 implementation with FIPS, or to pick up some nifty stickers. We look forward to seeing you there!
wolfSSL is a lightweight TLS/SSL library that is targeted for embedded devices and systems. It has support for the TLS 1.3 protocol, which is a secure protocol for transporting data between devices and across the Internet. In addition, wolfSSL uses the wolfCrypt encryption library to handle its data encryption.
Because there is a FIPS 140-2 validated version of wolfCrypt, this means that wolfSSL not only has support for the most current version of TLS, but it also has the encryption backbone to support your FIPS 140-2 needs if required.
Some key benefits of combining TLS 1.3 with FIPS validated software include:
- Software becomes marketable to federal agencies - without FIPS, a federal agency is not able to use cryptographic-based software
- Single round trip
- 0-RTT (a mode that enable zero round trip time)
- After Server Hello, all handshake messages are encrypted.
FIPS 140-2 is a government validation that certifies that an encryption module has successfully passed rigorous testing and meets high encryption standards as specified by NIST. For more information or details on FIPS 140-2, it may be helpful to view this Wikipedia article: https://en.wikipedia.org/wiki/FIPS_140-2
For more details about wolfSSL, TLS 1.3, or if you have any other general inquiries please contact firstname.lastname@example.org
Lighttpd master now supports wolfSSL with autoconf, meson, CMake, and SCons.
Build wolfSSL using:
./configure --enable-lighty make sudo make install
Build Lighttpd using:
cmake -DWITH_WOLFSSL=ON ..
This work was submitted via: https://github.com/lighttpd/lighttpd1.4/pull/92
Current documentation can be found here:
For more questions please email us at email@example.com.
MySQL (#mysql) currently comes bundled with yaSSL to provide an option for SSL/TLS connections when using a database. A patch for securing MySQL with the wolfSSL embedded SSL/TLS library is available for MySQL version 8.0.0 here https://github.com/wolfSSL/mysql-patch.
Along with an increased level of security comes the potential to use progressive features offered by wolfSSL – such as TLS 1.3 and ChaCha20 / Poly1305 AEAD cipher suites (ex: ECDHE-RSA-CHACHA20-POLY1305). Another great feature is that wolfSSL cryptography is FIPS 140-2 validated! Additionally, these features of wolfSSL are not mutually exclusive. For example, the FIPS 140-2 validation can be combined with wolfSSL’s support for TLS 1.3 for a lethal combination of security. The change from yaSSL to wolfSSL will fit nicely into both Open Source and commercial applications, as it is dual licensed under both GPLv2 and standard commercial license terms.
For more information about the port, or to provide us feedback, contact us at firstname.lastname@example.org!
wolfSSL is pleased to announce the following addition to the wolfSSL FIPS certificate!
|Debian 8.7.0||Intel ® Xeon® E3 Family with SGX support||Intel®x64 Server System R1304SP|
|Windows 10 Pro||Intel ® Core TM i5 with SGX support||Dell LatitudeTM 7480|
The wolfCrypt FIPS validated cryptographic module has been validated while running inside an Intel SGX enclave and examples have been setup for both Linux and Windows environments.
Intel ® SGX (Software Guard Extensions) can be thought of as a black-box where no other application running on the same device can see inside regardless of privilege. From a security standpoint this means that even if a malicious actor were to gain complete control of a system including root privileges, that actor, no matter what they tried, would not be able to access data inside of this “black-box”.
An Intel enclave is a form of user-level Trusted Execution Environment (TEE) which can provide both storage and execution. Meaning one can store sensitive information inside and also move sensitive portions of a program or an entire application inside.
While testing, wolfSSL has placed both individual functions and entire applications inside the enclave. One of the wolfSSL examples shows a client inside the enclave with the only entry/exit points being “start_client”, “read”, and “write”. The client is pre-programmed with a peer to connect with and specific functionality. When “start_client” is invoked it connects to the peer using SSL/TLS and executes the pre-programmed tasks where the only data entering and leaving the enclave is the info being sent to and received from the peer. Other examples show placing a single cryptographic operation inside the enclave, passing in plain-text data and receiving back encrypted data masking execution of the cryptographic operations.
If you are working with SGX and need FIPS validated crypto running in an enclave contact us at email@example.com or firstname.lastname@example.org with any questions. We would love the opportunity to field your questions and hear about your project!
The wolfSSL FAQ page can be useful for information or general questions that need need answers immediately. It covers some of the most common questions that the support team receives, along with the support team's responses. It's a great resource for questions about wolfSSL, embedded TLS, and for solutions to problems getting started with wolfSSL.
To view this page for yourself, please follow this link here.
Here is a sample list of 5 questions that the FAQ page covers:
- How do I build wolfSSL on ... (*NIX, Windows, Embedded device) ?
- How do I manage the build configuration of wolfSSL?
- How much Flash/RAM does wolfSSL use?
- How do I extract a public key from a X.509 certificate?
- Is it possible to use no dynamic memory with wolfSSL and/or wolfCrypt?
Have a question that isn't on the FAQ? Feel free to email 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.
This year, wolfSSL will be hosting an info session introducing wolfSSL and its applications, and will also be exhibiting at the Montana State University (MSU) 2018 Fall Career Fair.
The info session takes place on Monday, October 1st from 5:00pm-6:00pm. The info session will be hosted in Roberts Hall, room 113. For directions, please refer to the MSU map here: http://calendar.msu.montana.edu/locations.php?building=1&ref=map. There will be free pizza and stickers as well for attendees!
The info session will cover topics such as what wolfSSL is, the company background, products, and work environment. There will also be a live demo of the wolfSSL library in action, complete with Wireshark analysis. Additionally, there will be a chance for attendees to ask questions about wolfSSL's paid Summer internship program.
In addition to the info session, wolfSSL will be attending MSU's 31st Annual Fall Career Fair on Thursday, October 4th, for the duration of the fair. Manning the booth will be various senior employees throughout the event, along with some of wolfSSL's current interns. Feel free to stop by to drop off a résumé, get firsthand feedback about wolfSSL internships, or to introduce yourself to wolfSSL's Bozeman team.
Over the past year we have had multiple inquiries regarding Certificate Signing Request (CSR) generation from users looking to programatically generate a CSR using wolfSSL. To better assist our users with this feature we have setup a ready-made example in our GitHub examples repository and we are adding a section about CSR functionality to the wolfSSL manual. The example mentioned can be found using the link below:
The new manual section will be in chapter 7: Section 7.9 “Certificate Signing Request (CSR) Generation” and is located on our website here: https://www.wolfssl.com/docs/wolfssl-manual/ch7/
Some notes on CSR’s and wolfSSL:
To configure wolfSSL for CSR generation please add these options:
./configure --enable-certreq --enable-certgen
wolfSSL can generate a CSR for a requesting party which is then be sent to a Certificate Authority for use in issuing a certificate for that party.
wolfSSL can either generate a certificate from scratch with all mandatory fields set or it can generate a CSR from scratch with optional fields excluded.
As some items are deemed “optional” in a CSR that are otherwise “mandatory” in a certificate, wolfSSL’s parsing engine does not yet support consuming a CSR for use in generating a certificate. The wolfSSL parsing engine strictly checks all features required in a certificate and considers them to be mandatory. Passing in a CSR that does not contain these features results in an error from the parsing engine at this time. wolfSSL does not yet have a timeline for adding the additional parsing rules to allow CSR consumption but if this is a feature you would like to see added please send the wolfSSL team a note at firstname.lastname@example.org so an upvote can be added on your behalf to that feature enhancement! Unique users requesting a specific feature escalates the priority of that feature so let the wolfSSL team know!
If you have any questions concerning CSR generation, feedback on the example provided, or anything else for that matter, please contact us anytime at email@example.com! Our support staff are ready, wiling, and eager to help our end users in any way they can!
- October 2018 (8)
- 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)