RECENT BLOG NEWS
Differences between SSL and TLS Protocol Versions
Have you heard talk about SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 but never really knew the differences between the different versions? Secure Socket Layer (SSL) and Transport Security Layer (TLS) are both cryptographic protocols which provide secure communication over networks. These different versions are all in widespread use today in applications such as web browsing, e-mail, instant messaging and VoIP, and each is slightly different from the others.
wolfSSL’s embedded SSL/TLS library supports all of these protocols to best suit your needs and requirements. Below you will find lists comparing each version of the SSL/TLS protocols, detailing major changes and updates from version to version.
SSL 3.0
This protocol was released in 1996, but first began with the creation of SSL 1.0 developed by Netscape. Version 1.0 wasn`t released, and version 2.0 had a number of security flaws, thus leading to the release of SSL 3.0. Some major improvements of SSL 3.0 over SSL 2.0 are:
- Separation of the transport of data from the message layer
- Use of a full 128 bits of keying material even when using the Export cipher
- Ability of the client and server to send chains of certificates, thus allowing organizations to use certificate hierarchy which is more than two certificates deep.
- Implementing a generalized key exchange protocol, allowing Diffie-Hellman and Fortezza key exchanges as well as non-RSA certificates.
- Allowing for record compression and decompression
- Ability to fall back to SSL 2.0 when a 2.0 client is encountered
TLS 1.0
This protocol was first defined in RFC 2246 in January of 1999. This was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don`t interoperate. Some of the major differences between SSL 3.0 and TLS 1.0 are:
- Key derivation functions are different
- MACs are different – SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC.
- The Finished messages are different
- TLS has more alerts
- TLS requires DSS/DH support
TLS 1.1
This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:
- The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
- Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
- IANA registries are defined for protocol parameters
- Premature closes no longer cause a session to be non-resumable.
TLS 1.2
This protocol was defined in RFC 5246 in August of 2008. Based on TLS 1.1, TLS 1.2 contains improved flexibility. The major differences include:
- The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
- The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash. Signed elements include a field explicitly specifying the hash algorithm used.
- There was substantial cleanup to the client`s and server`s ability to specify which hash and signature algorithms they will accept.
- Addition of support for authenticated encryption with additional data modes.
- TLS Extensions definition and AES Cipher Suites were merged in.
- Tighter checking of EncryptedPreMasterSecret version numbers.
- Many of the requirements were tightened
- Verify_data length depends on the cipher suite
- Description of Bleichenbacher/Dlima attack defenses cleaned up.
TLS 1.3
This protocol is currently being revised, and is in its 28th draft. The major differences from TLS 1.2 include:
- The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
- A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- All handshake messages after the ServerHello are now encrypted.
- Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
- The handshake state machine has been restructured to be more consistent and remove superfluous messages.
- ECC is now in the base spec and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
- Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
- TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
- Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.
Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS Wikipedia article: http://en.wikipedia.org/wiki/Transport_Layer_Security
TLS 1.3 overview: https://www.wolfssl.com/docs/tls13/
As always, if you have any questions or would like to talk to the wolfSSL team about more information, please contact facts@wolfssl.com.
Differences between TLS 1.2 and TLS 1.3 (#TLS13)
wolfSSL's embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:
TLS 1.3
This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences include:
- The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
- A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- All handshake messages after the ServerHello are now encrypted.
- Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
- The handshake state machine has been restructured to be more consistent and remove superfluous messages.
- ECC is now in the base spec and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
- Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
- TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
- Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.
More information about the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/. Additionally, please contact facts@wolfssl.com for any questions.
Configuring the wolfSSH Lightweight SSH Library
wolfSSL provides many different embedded libraries and products, one of which is the wolfSSH Lightweight SSH library. wolfSSH is a lightweight SSHv2 server library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments - primarily because of its small size, speed, and feature set. It also includes many different example applications, such as an example client, echoclient, server, echoserver, and a port forwarding example.
To configure the library when downloading it from GitHub (https://github.com/wolfSSL/wolfssh), the first step required is to run the autogen.sh script from within the root directory of wolfSSH. This script sets up the library for use with autotools. Once the autogen.sh script has been run, the library can be configured as desired and then built. If downloaded from the wolfSSL website (https://www.wolfssl.com/download/) use of autogen.sh is not required. The configure script can take many features, some of which are outlined below:
--enable-debug | Add debug code - this turns off optimizations
(default: disabled) |
--enable-keygen | Enable key generation
(default: disabled) |
--enable-scp | Enable scp support
(default: disabled) |
--enable-sftp | Enable SFTP support
(default: disabled) |
--enable-fwd | Enable TCP/IP forwarding support
(default: disabled) |
All of the wolfSSH configure options can be viewed by running the configure script with the "-h" option. These configure options may also be prefixed with "--disable" as well, to disable features that are enabled by default.
The wolfSSH library can be downloaded by either cloning the wolfSSH GitHub repository (https://github.com/wolfssl/wolfssh.git), or by viewing the wolfSSL download page. For more information about using wolfSSH, please contact facts@wolfssl.com.
wolfSSL PKCS#11 Support
The wolfSSL embedded SSL/TLS library has support for PCKS#11! The PKCS#11 standard defines an API for using cryptographic tokens. The API added to wolfSSL will work with the most commonly used cryptographic object types (RSA keys, X.509 Certificates, DES/Triple DES keys, etc.) and all the functions needed to use, create, modify and delete those objects.
Using wolfSSL on your application or your device will now allow you to utilize PKCS#11 for access to hardware security modules, smart cards, and other cryptographic tokens. Interoperability of wolfSSL's PKCS#11 implementation has been tested against both OpenCryptoki, and SoftHSM2.
To build wolfSSL with PKCS#11 support, the library needs to be downloaded and then built with a specific configure flag or macro define. The library can be downloaded from the wolfSSL website, located here: https://www.wolfssl.com/download/. The steps to build and install with PKCS#11 are detailed below:
# From within wolfSSL's root directory ./autogen.sh ./configure --enable-pkcs11 make sudo make install
If the library is being built in a non-standard environment or autotools are not being used, then the macros HAVE_PKCS11 and HAVE_WOLF_BIGINT (used for some fastmath and ECC operations) need to be defined.
Documentation and more information about the PKCS#11 additions to wolfSSL arelocated within on the doxygen pages, here: https://www.wolfssl.com/doxygen/group__PKCS11.html
More information about the new release of wolfSSL v3.15.7 can be found here: https://www.wolfssl.com/wolfssl-3-15-7-now-available/
Wikipedia article on PKCS#11: https://en.wikipedia.org/wiki/PKCS_11
For more information about wolfSSL and PKCS#11 use contact us at facts@wolfssl.com.
wolfSSL Yocto Project Recipe
The wolfSSL embedded SSL/TLS library is highly portable, and easy to build on many different platforms. One of these platforms includes the Yocto Project, a project that assists developers with creating Linux-based systems on any architecture.
wolfSSL also includes many recipes and projects that make it easy to build on various platforms, and is maintained in the meta-wolfssl GitHub repository. This repository contains both Yocto and OpenEmbedded recipes for wolfSSL products (wolfSSL, wolfSSH, wolfMQTT, wolfTPM) and wolfSSL example applications. It also includes .bbappend files, which can be used to configure the cURL open-source project with support with the wolfSSL library.
More information about Yocto Linux and wolfSSL can be found in the meta-wolfssl readme, located in the GitHub repository here: https://github.com/wolfSSL/meta-wolfssl/blob/master/README.md
For more information on using wolfSSL, please contact facts@wolfssl.com.
wolfSSL 24×7 support
wolfSSL provides support on four levels, one of which is the 24x7 support level. This support level includes many key features not available on the others, such as an unlimited number of support incidents, around-the-clock support from dedicated members of the wolfSSL support team, and remains in effect for an entire year.
wolfSSL provides three other levels of paid support, which also include some of the same features provided by 24x7 support. More details on the wolfSSL support packages and levels can be viewed here: https://www.wolfssl.com/products/support-packages-options/
wolfSSL also provides support for the latest version of the TLS protocol, TLS 1.3! Read more about wolfSSL's implementation and the protocol itself here: https://www.wolfssl.com/docs/tls13/
For more information, please contact facts@wolfssl.com.
TLS 1.3 combined with FIPS (#FIPS #TLS13)
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.
And much more! For more information regarding the benefits of using TLS 1.3 or using the FIPS validated version of wolfCrypt, check out wolfSSL's TLS 1.3 Protocol Support and our wolfCrypt FIPS page.
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 facts@wolfssl.com
To find out more about FIPS, check out the NIST FIPS publications or contact fips@wolfssl.com
wolfSSL Asynchronous release 3.15.7 features
Release 3.15.7 of wolfSSL Async has bug fixes and new features including:
Summary
- All wolfSSL v3.15.7 fixes and features.
- Fixes for additional static analysis warnings and async edge cases (https://github.com/wolfSSL/wolfssl/pull/2003).
- Added QAT v1.7 driver support including support for QAT 8970 hardware.
- Added QAT SHA-3 support.
- Added QAT RSA Key Generation support.
- Added support for new usdm memory driver.
- Added support for detecting QAT version and features.
- Added `QAT_ENABLE_RNG` option to disable QAT TRNG/DRBG.
- Added alternate hashing method to cache all updates (avoids using partial updates).
Here are the latest benchmarks with various build configurations:
Asymmetric ops/sec | SW (CPU) | SW (SP) | HW QAT | HW Nitrox V | Symmetric MB/sec | SW (CPU) | SW (AESNI) | HW QAT | HW Nitrox V | |
RSA 2048 key gen | 12 | 12 | 147 | AES-128-CBC Enc | 939 | 5,028 | 3,454 | 238 | ||
RSA 2048 public | 10,679 | 118,922 | 271,142 | 140,699 | AES-128-CBC Dec | 926 | 5,585 | 3,464 | 238 | |
RSA 2048 private | 866 | 3,767 | 42,460 | 8,266 | AES-128-GCM | 22 | 5,517 | 3,341 | 133 | |
DH 2048 key gen | 2,915 | 7,559 | 48,931 | MD5 | 608 | 3,257 | 2,095 | |||
DH 2048 key agree | 3,026 | 7,477 | 68,351 | SHA | 394 | 1,533 | 2,225 | |||
ECDHE 256 agree | 4,376 | 54,119 | 56,805 | 10,503 | SHA-224 | 157 | 1,003 | 2,400 | ||
ECDSA 256 sign | 4,153 | 140,668 | 60,038 | 22,165 | SHA-256 | 152 | 1,003 | 2,401 | ||
ECDSA 256 verify | 5,404 | 43,689 | 32,853 | 7,361 | SHA-384 | 256 | 1,458 | 2,343 | ||
SHA-512 | 263 | 1,458 | 2,314 | |||||||
SHA3-256 | 742 | 860 | 2,565 | |||||||
Performed on an Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 16GB RAM, 8 threads, wolfSSL v3.15.7, QuickAssist v1.7 8970 PCIe 16x OR Cavium Nitrox V CNN5560-900-C45 |
CPU: ./configure --enable-keygen --enable-sha3
SP/AESNI: ./configure --enable-sp --enable-sp-asm --enable-aesni --enable-intelasm --enable-intelrand --enable-keygen --enable-sha3
QAT: ./configure --with-intelqa=../QAT1.7 --enable-asynccrypt --enable-keygen --enable-sha3
Nitrox V: ./configure --with-cavium-v=../CNN55XX-SDK --enable-asynccrypt
If you are interested in evaluating the wolfSSL Asynchronous support for Intel QuickAssist or Cavium Nitrox, please email us at facts@wolfssl.com.
wolfSSL Embedded SSL for Bare Metal and No OS Environments
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)
- Threading
- 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.
To learn more about how to integrate wolfSSL into your environment or get more information about reducing wolfSSL’s memory usage, please see the wolfSSL Manual or contact us directly.
wolfSSL FAQ page
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 support@wolfssl.com.
Weekly updates
Archives
- January 2025 (7)
- December 2024 (22)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- 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)