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.

Differences between SSL and TLS Protocol Versions (#TLS13)

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 supports all three of these ciphers to best suit your needs and requirements. Below you will find the major differences between the different protocol versions.

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

Netscape`s Original SSL 3.0 Draft: http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt
Comparison of SSLv2 and SSLv3: http://stason.org/TULARC/security/ssl-talk/4-11-What-is-the-difference-between-SSL-2-0-and-3-0.html

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

RFC 2246: http://tools.ietf.org/html/rfc2246

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.

RFC 4346: http://tools.ietf.org/html/rfc4346#section-1.1

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.

RFC 5246: http://tools.ietf.org/html/rfc5246

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.

RFC 8446: https://tools.ietf.org/html/rfc8446

Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS – Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL versus TLS – What`s the Difference? (http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html)
Cisco – SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)

As always, if you have any questions or would like to talk to the wolfSSL team about more information, 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.

wolfSSL at MtoM Embedded Systems 2019

wolfSSL is at MtoM Embedded Systems this year! This year's MtoM event features two adjoined conferences and exhibitions: Embedded Systems and Connected Objects. Attendees will have access to speaker sessions and workshops addressing the ever-growing number of network connections worldwide and the emerging technologies that support, measure and secure the IIoT and our connected world. For 2019, MtoM Embedded will be held at Paris expo Porte de Versailles, in Paris, France.

Where wolfSSL will be located for MtoM Embedded:

Venue: Paris expo Porte de Versailles
Stand #: B12
When: March 20, 21
Directions: http://www.embedded-mtom.com/infos_pratiques.php

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 facts@wolfssl.com.

wolfSSL ESP32 Hardware Acceleration Support

wolfSSL is excited to announce support for Espressif ESP32 hardware acceleration to the wolfSSL embedded SSL/TLS library!

The ESP32-WROOM-32 is a powerful, generic Wi-Fi+BLE MCU module with high flexibility, and is easily interactable with the wolfSSL embedded SSL/TLS library. As wolfSSL is highly portable and the ESP32-WROOM-32 is highly flexible, if your application has any special features that interfere with the existing wolfSSL port, they are easily remedied.

The new wolfSSL ESP32-WROOM-32 port functionality was added into the existing ESP-IDF port, and the ESP32-WROOM-32 functionality can be enabled by either defining the "WOLFSSL_ESPIDF" and “WOLFSSL_ESPWROOM32” or “WOLFSSL_ESPWROOM32SE” options in the settings.h file (or user_settings.h alternatively, if WOLFSSL_USER_SETTINGS is defined). For more details about this new ESP32 support, please see the REAMDE.md placed in the “<wolfssl-root>/wolfcrypt/src/port/Espressif” directory of the wolfSSL source tree. Details about the ESP-IDF port can be found in the README.md file located in "<wolfssl-root>/IDE/Espressif/".

wolfSSL's support for the onboard hardware cryptography of the ESP32 and ATECC608A gives users code size reductions and performance advantages.  A full set of benchmarks and performance comparisons can be found on our ESP32-specific webpage, located here: https://www.wolfssl.com/docs/espressif/.

Espressif ESP32-WROOM-32SE, Beta

The wolfSSL master branch can be cloned from here: https://github.com/wolfSSL/wolfssl
The README about ESP-IDF porting can be found here: https://github.com/wolfSSL/wolfssl/blob/master/IDE/Espressif/ESP-IDF/README.md
The README about HW acceleration can be found here: https://github.com/wolfSSL/wolfssl/blob/master/wolfcrypt/src/port/Espressif/README.md
The README about 32SE can be found here: https://github.com/wolfSSL/wolfssl/blob/master/IDE/Espressif/ESP-IDF/README_32se.md

For more information, please contact facts@wolfssl.com.

Resources:
ESP32-WROOM-32 Overview: https://www.espressif.com/en/products/hardware/esp-wroom-32/overview

wolfSSL at Medtec Japan 2019

wolfSSL is at Medtec Japan this year! Medtec Japan is the largest medical device manufacturing and design show in Asia, and will showcase the best of the industry. For 2019, Medtec will be held at the Tokyo Big Sight International Exhibition Center.

Where wolfSSL will be located at Medtec:

Venue: Tokyo Big Sight, Tokyo, Japan
Booth #: 3105, EAST hall 5
Date and time: March 18-20, 10:00-17:00
Directions: http://www.bigsight.jp/access/transportation/ (English)

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 facts@wolfssl.com.

wolfSSL support for the ATECC508A/ATECC608A crypto coprocessor

wolfSSL embedded SSL/TLS support the latest Microchip ATECC508A and ATECC608A I2C cryptographic coprocessors. Not only is wolfSSL compatible with CryptoAuthLib, wolfSSL has also been tested on both the 508A and the 608A.

Prerequisites:

Examples:

  • wolfSSL uses PK (Public Key) callbacks for the TLS crypto operations
  • wolfCrypt uses the WOLFSSL_ATECC508A macro to enable native wc_ecc_* API support
  • wolfCrypt also uses the WOLFSSL_

The README.md and reference PK callbacks can be found here: https://github.com/wolfSSL/wolfssl/tree/master/wolfcrypt/src/port/atmel

Additional demos for wolfSSL TLS Client/Server and wolfCrypt test/benchmarks can be found:

https://www.wolfssl.com/download/downloadMoreForm.php
https://github.com/dgarske/atmel

Preprocessor Macros:

  • WOLFSSL_ATECC508A
  • WOLFSSL_ATECC_PKCB
  • WOLFSSL_ATMEL

PK Callbacks:

wolfSSL’s TLS layer PK callbacks expose API’s to set ECC callbacks. These are enabled with: #define HAVE_PK_CALLBACKS or ./configure --enable-pkcallbacks.

Reference API’s:

  • atcatls_create_key_cb
  • atcatls_verify_signature_cb
  • atcatls_sign_certificate_cb
  • atcatls_create_pms_cb

For more questions please email us at facts@wolfssl.com.

wolfSSL at RSA Conference 2019

wolfSSL is at RSA Conference again this year! RSA Conference is an event geared towards cybersecurity, the encryption professionals of the world, and is an incredible way to meet professionals or learn about the current security industry. For 2019, RSA Conference is being held from March 4th to March 8th at the Moscone Center in San Francisco, California.

Where wolfSSL will be located for RSA:

Building: North Hall
Booth #: 6470
When: March 4th - 8th
Directions: https://www.rsaconference.com/events/us19/hotels-venue/directions-parking

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 facts@wolfssl.com.

wolfCrypt v4 FIPS

Recently, the National Institute of Standards and Technology (NIST) completed the validation of the wolfCrypt module version 4 for an updated Federal Information and Processing Standards (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 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, 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.

Other information can be obtained, or questions can also be answered by contacting facts@wolfssl.com.

Building Secure Socket Funneling (SSF) with wolfSSL

wolfSSL can now be used to replace OpenSSL in Secure Socket Funneling (SSF)!

Secure Socket Funneling (SSF) is a network tool and toolkit. It provides simple and efficient ways to forward data from multiple sockets (TCP or UDP) through a single secure TLS tunnel to a remote computer.

Features:

  • Local and remote TCP port forwarding
  • Local and remote UDP port forwarding
  • Local and remote SOCKS server
  • Local and remote shell through sockets
  • File copy
  • Native relay protocol
  • TLS connection with the strongest cipher-suites

Since SSF is dependent on Boost.Asio for TLS purposes and Boost.Asio is now compatible with wolfSSL (see blog post), you now have the option to run SSF with wolfSSL’s high standard of internet security.

If you are interested in using wolfSSL with SSF in your project, please contact us at facts@wolfssl.com and we will happily provide you with the needed source code and instructions on how to build everything together successfully.

Posts navigation

1 2