RECENT BLOG NEWS
So, what’s new at wolfSSL? Take a look below to check out the most recent news.
wolfSSL now supports Xilinx SoCs and FPGAs. The wolfSSL embedded SSL/TLS library can be used with FPGAs which use the MicroBlaze CPU and/or Zynq and Zynq UltraScale+ SoCs. Improved performance speeds with using the hardware crpyto can be seen. Increasing AES-GCM, RSA, and SHA3 operations performance. In addition to the performance gained a user also gets the additional security the hardware provides while executing the algorithms.
For more information contact
wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. wolfSSL develops, markets and sells the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.
Currently, we are seeking to add a senior level C software engineer with 5-10 years experience interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus. Experience with hardware-based cryptography is a plus.
Operating environments of particular interest to us include Linux, Windows, Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments such as Android and iOS is also a plus, but not required.
Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.
How To Apply
To apply or discuss, please send your resume and cover letter to [email protected].
wolfSSL is cited in the recent ROBOT Attack by Böck, Somorovsky, and Young. The paper notes that wolfSSL only gives a weak oracle without a practical attack but this is still a flaw. We’ve posted a fix for this and a general release will be available next week. Please note that wolfSSL has disabled static RSA cipher suites by default as of version 3.6.6 because of the lack of perfect forward secrecy. Only users who have explicitly enabled static RSA cipher suites with WOLFSSL_STATIC_RSA and use those suites on a host are affected.
Contact [email protected] if you have any questions or concerns.
We decided to benchmark our wolfCrypt/wolfSSL libraries on Apple’s new A11 processor in their latest iPhone 8 / 8 Plus and iPhone X. This processor features six ARMv8 CPU cores (2 high-performance 2.53GHz and 4 high-efficiency 1.42GHz). The benchmarks use wolfSSL’s latest speedups for ARMv8 crypto extensions and single precision math to demonstrate our exceptional performance.
For symmetric AES and SHA using our ARMv8 crypto assembly speedups we see:
AES-128 CBC Encrypt: 912.347 MB/s (36.58X)
AES-128 CBC Decrypt: 6,084.83 MB/s (256.15X)
AES-128 GCM Encrypt: 1,242.28 MB/s (193.65X)
AES-128 GCM Decrypt: 575.83 MB/s (90.26X)
SHA-256: 1,717.28 MB/s (56.11X)
This feature is enabled using `./configure –enable-armasm` or the `WOLFSSL_ARMASM` define.
For asymmetric RSA, DH and ECC using our single precision math speedups we see:
RSA 2048 public: 1,211.27 ops/sec (1.50X)
RSA 2048 private: 32.59 ops/sec (1.18X)
DH 2048 key gen: 77.44 ops/sec (1.24X)
DH 2048 key agree: 77.45 ops/sec (1.29X)
ECC 256 key gen: 1670.65 ops/sec (8.67X)
ECDHE 256 agree: 396.88 ops/sec (2.05X)
ECDSA 256 sign: 1,212.33 ops/sec (6.42X)
ECDSA 256 verify: 331.02 ops/sec (2.38X)
This feature is enabled using `./configure –enable-sp` or the `WOLFSSL_HAVE_SP_RSA`, `WOLFSSL_HAVE_SP_DH` and `WOLFSSL_HAVE_SP_ECC` defines.
For TLS v1.2 we see the following performance benchmarks by cipher suite:
DHE-RSA-AES128-SHA256: CPS 22.5, Read 388 MB/s, Write 106 MB/s
ECDHE-RSA-AES128-GCM-SHA256: CPS 26.2, Read 598 MB/s RX, Write 125 MB/s
ECDHE-ECDSA-AES128-GCM-SHA256: CPS 83.4, Read 504.8 MB/s, Write 92.2 MB/s
Benchmarks done on iPhone X using a single thread and our wolfCrypt and wolfSSL benchmark tools.
`X`= performance increase as compared to our default software based implementation.
`CPS` = Connections per second
You can download the raw benchmark numbers here:
You can find the Xcode iOS benchmark project used here:
Or in the wolfSSL repository in `IDE/XCODE/Benchmarks`
For questions please email us at [email protected]
Come join wolfSSL at the Embedded Systems Conference
The wolfSSL team will be in San Jose December 6-7, 2017 for the Embedded Systems Conference (ESC) Silicon Valley. This event will be held at the San Jose Convention Center in California from 10:00am to 4:00pm Wednesday and Thursday.
If you are attending or planning on attending please stop by our booth, #1728, or schedule an appointment to talk SSL/TLS and cryptography at the show. You can contact the wolfSSL team at (425) 245-8247 or by email at [email protected] We’ll be talking about securing embedded devices with wolfSSL, wolfCrypt, wolfMQTT, and wolfSSH!
For more information about ESC Silicon Valley, visit:
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! 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 [email protected]!
wolfMQTT v0.14 has been released (11/22/17) and includes fixes for non-blocking operation, improved error handling with TLS, fixes for GCC 7 warnings and updates to the Visual Studio projects.
wolfSSL will be at the IoT Tech Expo (Nov 29-30, 2017) in Santa Clara at the convention center. If you are attending please visit our booth #196 and say hello. Our MQTT expert David Garske will be available to answer questions.
wolfMQTT v0.14 Release Notes:
- Fixed non-blocking connect to check for `EINPROGRESS` for all platforms (not just Harmony).
- Fixed buffer overflow position check on read/write.
- Fixed typo on internal packet function `MqttDecode_ConnectAck`.
- Fixed the socket close for Harmony to use `closesocket`.
- Fixed non-blocking connect where `WOLFMQTT_NO_STDIO` is defined.
- Fixed GCC 7’s new fall-through check.
- Added check for EAGAIN in non-blocking mode (was only EWOULDBLOCK).
- Added non-blocking support for write operations when `WOLFMQTT_NONBLOCK` is defined.
- Added support for DH and setting the default minimum key bits.
- Added support for keep-alive ping when using non-blocking mode.
- Improvements to example TLS callback handling of return code failures.
- Improvements and fixes to Visual Studio projects.
- Enhancement to adjust wolfSSL options.h include based on `WOLFSSL_USER_SETTINGS`.
You can download the latest release here: https://www.wolfssl.com/download/
For questions please email us at [email protected]
wolfSSL will be exhibiting at the IoT North America Expo this week in Santa Clara, CA. The event runs November 29-30, 2017 and is held at the Santa Clara Convention Center in Silicon Valley. wolfSSL will be exhibiting in Stand 196. We’ll be talking about securing IoT and resource-constrained devices with the wolfSSL lightweight SSL/TLS library, wolfMQTT client library, wolfCrypt cryptography library, and wolfSSH server.
For those of you who are not familiar with the IoT Expo, from the conference site:
The World’s Largest IoT Event Series will bring together key industries from across America for 2 days of top level content and discussion. Introducing and exploring the latest innovations within the Internet of Things and covering Manufacturing, Transport, Health, Logistics, Government, Energy and Automotive, this conference is not to be missed.
If you would like to schedule an on-site meeting with wolfSSL, please let us know at [email protected]
The TLS v1.3 specification has been evolving over the year and is close to being finalized. Recently the code changes required to support Draft 21 were added to wolfSSL.
Most browsers and servers on the Internet are stuck on Draft 18. This maximizes interoperability and allows for collection of error rate statistics. wolfSSL is able to be compiled to support TLS v1.3 Draft 18 but also the latest draft version. The Draft 21 changes were quite minor but introduced one wire protocol change: a per-ticket nonce.
Resumption in TLS v1.3 is performed with session tickets. The ticket contains enough information to indicate to the server which session is being resumed. Most often the ticket contains self-encrypted session information. Alternatively, the ticket can be a reference into a session database that identifies the client.
Note that in previous drafts, on resumption, the Resumption Master Secret (RMS) from the original connection is used as the Pre-Shared Key (PSK). The PSK is used to derive the secrets for the new handshake. Therefore all handshakes resumed from the same ticket will have the same secrets unless (EC)DH is used.
Draft 21 adds a nonce to the NewSessionTicket message that is used, with the RMS, to securely derive a unique PSK for a resumption handshake. Multiple single-use resumption tickets can now be sent with the same database reference but a different nonce and be deleted on use. Each resumption ticket produces unique secrets and provides forward-secrecy protection if a PSK is compromised.
As noted above, there are not many other implementations of Draft 21 out there. Client and server interoperability testing with OpenSSL though was performed to ensure compatibility.
Most handshakes performed will be by resumption where possible as they are faster than a full handshake. Improving resumption security therefore is a big plus and makes using the latest updates of wolfSSL a must.
The security of wolfSSL products is always on our mind and holds high importance. Conducting regular, diligent, and well-planned testing helps maintain wolfSSL’s robustness and security. We strive to write and maintain clean, readable, and understandable code.
Like the halting problem, we know it is impossible to test every single possible path through the software, but we practice an approach that is focused on lowering risk of failure. In addition to extensive automated testing, we make sure that we specifically test well-known use cases. This post outlines some of our internal testing process.
API Unit Testing: We have unit tests in place that test API functions for correct behavior. This helps maintain library consistency across releases and as the code evolves. It helps us to deliver a high quality, well tested API to our end users with each software release. API unit tests are run with each “make check” of wolfSSL.
Cipher Suite Testing: wolfSSL supports an extensive list of cipher suites, which are all tested with every “make check” using the wolfSSL example client and example server. Each cipher suite is tested not only in the default configuration, but also in non-blocking mode and with client authentication both turned on/off.
Algorithm Testing: The security of our SSL/TLS implementation depends on the correctness and robustness of our underlying cryptography library, wolfCrypt. We test all algorithms using NIST test vectors in addition to running our CAVP test harness used for our FIPS 140-2 validations. We also test on both big and little endian platforms for portability.
Benchmark Testing: We engage in another ever expanding universe of benchmark testing, where we look at sizing, transmission rates, connection speeds, and cryptography performance. A version of our benchmark suite is included in every download for users to enjoy!
Static Analysis: We do static analysis on our entire codebase using not only one, but multiple different static analysis tools. We currently use Coverity Scan, clang scan-build, and Facebook infer. These tools help us to automatically find bugs including ones on low-traffic code paths.
Detecting Memory Errors: We mitigate memory errors by using valgrind on a regular and automated basis. This helps find memory errors including invalid access, use of undefined values, incorrect freeing of dynamic memory, and memory leaks.
Interop Testing: We test for interoperability with other Open Source TLS implementations, including OpenSSL, BoringSSL, and GnuTLS. This helps us to catch any protocol implementation errors in either wolfSSL or the implementation being tested against. We also test outside of a closed environment by connecting to servers in the real world running unknown SSL/TLS implementations.
Real World Builds: We build with a series of ‘real’ applications, like cURL, wget, pppd, OpenSSH, stunnel, lighttpd, etc. For some of our customers with top level support, we build new releases with their application.
Compiler Testing: We have users who compile wolfSSL with a variety of different compilers. As such, we test compiling wolfSSL with many different compilers and toolchains including gcc/g++, clang, icc, Visual Studio, CodeWarrior, KDS, LPCXpresso, MPLAB XC, TI CCS, Keil, IAR, Cygwin, MinGW, CrossWorks, Arduino, Wind River Workbench, and more.
Peer Review: More eyes on a codebase reduces bugs that end up in a final product. Internally, we operate using a “Fork and Pull Request” model. This means that every commit that makes it into our master branch has been reviewed and tested by at least two separate engineers.
Third Party Testing: Our code is regularly reviewed by university researchers, customer and user security teams, FIPS and certification labs, and our Open Source user base. This helps put more eyes on our code and product architecture.
Fuzz Testing: We test using several different software fuzzers, including an in-memory fuzzer, a network fuzzer, OSS-fuzz, libfuzzer, tlsfuzzer, and AFL. Fuzz testing bombards the program with invalid, unexpected, and random data that then allows for observing if there is potential memory leaks or logic errors. This allows us to catch bugs that could turn into potential vulnerabilities if released in a final release.
- Protocol Analysis: TLS-Attacker, a Java-based framework for analyzing TLS libraries, helps us analyze that wolfSSL correctly conforms to the SSL/TLS specification.
Continuous Integration (CI): Leveraging Jenkins, we run tests on each commit submitted to the wolfSSL code repository. Tests run on each commit include testing of our FIPS build, numerous build options (customer/user/common), running valgrind, and doing static analysis with scan-build.
Nightly Test Cycle: Each night we run extended tests that last longer than the typical ones during the work day. These are more in-depth than our CI testing and puts results in our engineers’ inboxes each morning. Some tests included in our nightly cycle include extended build option testing on multiple platforms with multiple compilers, and extended fuzz testing.
If you have specific questions about how we test, please contact us at [email protected]. If you would like us to include your SSL/TLS or crypto implementation in our interop testing, please let us know! Likewise, if you would like to include wolfSSL in your own test framework, we would be happy to discuss.
- December 2017 (5)
- November 2017 (14)
- October 2017 (9)
- September 2017 (11)
- August 2017 (11)
- July 2017 (12)
- June 2017 (9)
- May 2017 (11)
- April 2017 (6)
- March 2017 (8)
- February 2017 (2)
- January 2017 (10)
- December 2016 (4)
- November 2016 (4)
- October 2016 (20)
- September 2016 (11)
- August 2016 (8)
- July 2016 (5)
- June 2016 (11)
- May 2016 (4)
- April 2016 (6)
- March 2016 (4)
- February 2016 (15)
- January 2016 (7)
- December 2015 (4)
- November 2015 (11)
- October 2015 (6)
- September 2015 (7)
- August 2015 (11)
- July 2015 (9)
- June 2015 (11)
- May 2015 (2)
- April 2015 (4)
- March 2015 (14)
- January 2015 (9)
- December 2014 (9)
- November 2014 (3)
- October 2014 (3)
- September 2014 (11)
- August 2014 (7)
- July 2014 (10)
- June 2014 (12)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (7)
- January 2014 (7)
- December 2013 (11)
- November 2013 (6)
- October 2013 (9)
- September 2013 (3)
- August 2013 (10)
- July 2013 (7)
- June 2013 (5)
- May 2013 (8)
- April 2013 (5)
- March 2013 (2)
- February 2013 (3)
- January 2013 (11)
- December 2012 (13)
- November 2012 (7)
- October 2012 (8)
- September 2012 (5)
- August 2012 (7)
- July 2012 (5)
- June 2012 (5)
- May 2012 (7)
- April 2012 (8)
- March 2012 (6)
- February 2012 (7)
- January 2012 (9)
- December 2011 (5)
- November 2011 (7)
- October 2011 (8)
- September 2011 (8)
- August 2011 (6)
- July 2011 (4)
- June 2011 (8)
- May 2011 (12)
- April 2011 (6)
- March 2011 (13)
- February 2011 (12)
- January 2011 (16)
- December 2010 (19)
- November 2010 (17)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (16)
- 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)