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.
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.
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 firstname.lastname@example.org.
wolfSSH is a portable embedded SSH solution developed by wolfSSL. Recently we have made an exciting new feature enhancement to allow for client side support of pseudo terminal connections. This feature can be turned on by using the configure flag --enable-term and running the example client with “-t” ( i.e. ./examples/client/client -t -h <ip> -u <username> -p <port #> ). In addition to the added enhancement of using pseudo terminals, a function was added to support console code translations from Linux to Windows terminals. This allows usage of client side wolfSSH pseudo terminals on a Windows machine when connecting to a Linux server.
Another feature that was added is the ability for sending execution commands from the client to a server. An SSH connection to execute a command can be done by using the “-c” flag with the example SSH client. (i.e. ./examples/client/client -h <ip> -u <username> -p <port #> -c <command> ) There are many use cases for this, one being the case where an embedded system wants to startup a program on another device or server and pipe input / output through the secure wolfSSH connection.
These new features can be found at the wolfSSH github repository https://github.com/wolfSSL/wolfssh and in the next release version of wolfSSH on the wolfSSL website here https://www.wolfssl.com/download/.
For more information contact us at email@example.com.
Recently, wolfSSL released version 3.15.5 of the wolfSSL embedded SSL/TLS library. This new release features many feature additions and updates, one of which is the added support for using public key callbacks with TLS on an STSAFE-A100.
The STSAFE-A100 is a highly secure solution that acts as a secure element providing authentication and data management services to a local or remote host. When paired with wolfSSL, this results in a robust and secure device that is able to effectively prevent external malicious attacks and provide high-strength, fast encryption.
For more information about the release or about wolfSSL, please contact firstname.lastname@example.org.
wolfSSL version 3.15.5 release notes: https://www.wolfssl.com/wolfssl-3-15-5-now-available/
Recently, wolfSSL released version 3.15.5 of the wolfSSL embedded SSL/TLS library. This new release contains various updates and feature additions to the wolfSSL library, including the addition of Renesas RX e2 studio project files.
Renesas e2 studio is a development environment based on the Eclipse IDE. It covers various building tasks (editing, compiling, linking, etc.) and also provides a debug interface. It can use a wide range of compilers, including all Renesas compilers. This tool allows developers to more easily create and manage their project on their Renesas embedded controllers.
The addition of the wolfSSL studio project files for this tool is a great game changer, as it allows developers to use the portable, low-resource use wolfSSL library. wolfSSL uses the most secure and up-to-date encryption schemes that are offered by the wolfCrypt encryption engine, and also provides support for TLS 1.3! This way, Renesas embedded controllers can use high-end encryption with the latest version of the TLS protocol.
To find out more information, please contact email@example.com.
wolfSSL v3.15.5 release notes: https://www.wolfssl.com/wolfssl-3-15-5-now-available/
Recently, wolfSSL released version 3.15.5 of the wolfSSL embedded SSL/TLS library. This new release features many new additions and updates, including the addition of a port for the STM32L4 MCU.
The STM32L4 is an ultra-low-power device with high flexibility, and as a member of the STM32 family, is easily integratable with the wolfSSL library. As wolfSSL is highly portable and the STM32L4 is highly flexible, if your device has any special features that interfere with the wolfSSL port, they are easily remedied.
The new wolfSSL STM32 port functionality was added into the existing STM32 port, and the STM32L4 functionality can be enabled by either defining the "WOLFSSL_STM32L4" option in the user_settings.h file, or by including the option CPPFLAGS="-DWOLFSSL_STM32L4" to the configure script if building the wolfSSL library with autotools.
Additionally, wolfSSL also provides support for the latest version of the TLS protocol, TLS 1.3! Find more information about TLS 1.3 here: https://www.wolfssl.com/docs/tls13/
For more information, please contact firstname.lastname@example.org.
The wolfSSL (formerly CyaSSL) embedded SSL library supports lwIP, the light weight internet protocol implementation, out of the box. The user merely needs to define
WOLFSSL_LWIP or uncomment the line
/* #define WOLFSSL_LWIP */ in os_settings.h to use wolfSSL with lwIP.
The focus of lwIP is to reduce RAM usage while still providing a full TCP stack. That focus makes lwIP great for use in embedded systems, the same area where wolfSSL is an ideal match for SSL/TLS needs. An active community exists with contributor ports for many systems. Give it a try and let us know if you have any suggestions or questions.
For the latest news and releases of lwIP, you can visit the project homepage, here: http://savannah.nongnu.org/projects/lwip/
wolfSSL has added support for using the AF_ALG and Cryptodev-linux Linux modules. These are modules that can be loaded into a Linux kernel and allow access to the Linux crypto drivers. Having access to the Linux crypto drivers gives the ability to leverage hardware acceleration that the kernel has in place. One such use case being when running Linux on an embedded i.MX6 IoT board and wanting to access CAAM drivers provided by Linux.
To build wolfSSL with AF_ALG support use the enable option --enable-afalg
To build with Cryptodev-linux support use --enable-devcrypto.
The current supported algorithms are SHA256 and AES.
For more information or if you need assistance using the wolfSSL embedded SSL/TLS on your platform, please feel free to contact email@example.com.
Contiki is an open source operating system for the Internet of Things. It connects tiny low-cost, low-power microcontrollers to the Internet. Contiki is a perfect match for wolfSSL, which was built for use on embedded and resource-constrained devices with portability in mind. In addition to being highly portable, wolfSSL provides support for the latest and greatest version of the TLS protocol, TLS 1.3! Using the wolfSSL port with your device running Contiki will allow your IoT device to connect to the internet in one of the most secure ways possible.
The Contiki port in wolfSSL is activated by using the "WOLFSSL_CONTIKI" macro when compiling wolfSSL. An example of this on embedded devices would be placing WOLFSSL_CONTIKI into a user_setttings.h file, or by including the option CPPFLAGS="-DWOLFSSL_CONTIKI" if compiling wolfSSL by using autotools.
For more information, please contact firstname.lastname@example.org.
The most recent version of wolfSSL can be downloaded from our download page, here: https://www.wolfssl.com/download/
wolfSSL support for TLS 1.3: https://www.wolfssl.com/docs/tls13/
Contiki OS homepage: http://www.contiki-os.org
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.
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
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
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.
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
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
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 email@example.com.
- February 2019 (6)
- 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 (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)