Month: April 2023

Have you heard the news from the OpenSSL blog?  If you are using the 1.1.1 branch of releases of OpenSSL, come September 11, 2023, there will be no more updates. You can get the details here: 

https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/   

That said, you can breathe a sigh of relief because wolfSSL is here to help.  We have three ways to help.

Compatibility Layer

During the configure step of building wolfSSL, simply use –enable-opensslall and that will turn on our compatibility layer.  Your application build will then have to point to wolfSSL’s include path and binary library file. You should not need to change your source code.  That said, if you find you are getting build errors about missing APIs, please send a message to support@wolfssl.com. We would love to help you keep your code base as clean and simple as possible.

wolfEngine

There are some cases where the compatibility layer might not be appropriate. For example, you might be directly modifying members of OpenSSL’s structures since not all of them are hidden. For such cases, we have wolfEngine. You can continue using OpenSSL, but under the hood the wolfCrypt implementations of the cryptographic algorithms will be used. This might be especially useful if you are looking for an accelerated path to FIPS certification.

wolfProvider

Perhaps you have already gone through the work of migrating to the OpenSSL 3.0.x branches. Noticing any performance issues? Having trouble finding help or getting support? The wolfSSL team is known for having the fastest cryptographic implementations and providing excellent support. Why not try out wolfProvider to see if it can help your project?  Like wolfEngine, if you are looking for an accelerated path to FIPS certification, this might be your solution.No matter your circumstances, we are here to help you through this trying time as OpenSSL ends support for the 1.1.1 series of releases. If you have any questions, please contact us at facts@wolfssl.com.

If you’re interested in learning more about SSL/TLS or the wolfSSL lightweight SSL library, then you’re in luck. wolfSSL is offering a free 2-day (4 hours each day) training course on wolfSSL.

The next instance of this training course will take place April 19th & 20th from 12:00 PM to 5:00 PM (UTC) both days. This instance was scheduled to accommodate European timezones, soon we will announce an instance that will accommodate Asia time zones.

The course includes Q&A sessions throughout the webinar. To get full access to the course, participants must register for both days. If you’re interested in learning more about SSL/TLS or the wolfSSL library, this training course is an excellent opportunity to deepen your knowledge and skills in this area.

Day 1: https://us02web.zoom.us/webinar/register/1616774545098/WN_6ajXwan9SNmXRxgws81euA 

Day 2: https://us02web.zoom.us/webinar/register/1616774545098/WN_kG4dCqwWSs6YGyiCgQmC8w 

The course objectives are to provide attendees with a basic understanding of how SSL/TLS work, learn the package and design of wolfSSL, effectively build wolfSSL for target platforms, learn effective wolfSSL debugging strategies, add wolfSSL to different client and server applications, learn best practices for adding wolfSSL to embedded, desktop/enterprise, or cloud applications or devices, and develop using wolfSSL’s underlying cryptography library.

If you are working towards CISSP (Certified Information Systems Security Professional) certificate this training webinar could qualify for Group A Credits as a domain related activity. Send an email to facts@wolfssl.com if you require proof of attendance post webinar.

wolfSSL implements support for both client side and server side DTLS. The server side requires extra attention when it comes to Denial-of-Service (DoS) attacks. One way to mitigate DoS on DTLS servers is to operate statelessly until a cookie exchange is completed with the peer. The cookie exchange is implemented in all versions of DTLS. DTLS 1.2 uses a special HelloVerifyRequest message while DTLS 1.3 uses the TLS 1.3 HelloRetryRequest with a cookie extension. The general principle of the cookie exchange is shown in the following figures.

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                            <----- HelloVerifyRequest
                                   (contains cookie)
      ClientHello           ------>
      (with cookie)

      [Rest of handshake]

Figure 1: DTLS 1.2 cookie exchange (https://www.rfc-editor.org/rfc/rfc6347#section-4.2.1)

      Client                                   Server
      ------                                   ------
      ClientHello           ------>

                            <----- HelloRetryRequest
                                   + cookie
      ClientHello ------>
       + cookie

      [Rest of handshake]

Figure 2: DTLS 1.3 cookie exchange (https://www.rfc-editor.org/rfc/rfc9147.html#section-5.1)

The trick is to parse the initial ClientHello without maintaining state. In wolfSSL release 5.6.0, we implemented parsing the initial ClientHello without maintaining state at all (https://github.com/wolfSSL/wolfssl/pull/5910). Previously, wolfSSL would reset the object when requesting a cookie exchange but this can be unreliable on errors or when new features are implemented. Now we have a dedicated routine to parse the ClientHello statelessly.

wolfSSL also has a callback available when a peer has been verified. To set this callback, use the int wolfDTLS_SetChGoodCb(WOLFSSL* ssl, ClientHelloGoodCb cb, void* user_ctx) API.

Contact us at facts@wolfssl.com with any questions or for help integrating wolfSSL DTLS support into your application or project.

wolfSSL Inc is proud to announce an important incremental update to wolfSSH: v1.4.13!

In this release, we fix a severe user authentication bug in wolfSSHd. It is highly recommended that anyone using wolfSSHd upgrade to this version immediately (see Vulnerabilities in the change log below).

We have added a STM32Cube Expansion Pack for building in that environment. The daemonization and test coverage of wolfSSHd has been improved. We also improved support for transferring large files with SFTP. We also have a testbed for checking wolfSSH with LwIP using both FreeRTOS and Linux.

The release information from the change log is reposted below:

wolfSSH v1.4.13 (Apr 3, 2023)

New Feature Additions and Improvements

• Improvement to forking the wolfSSHd daemon.
• Added an STM32Cube Expansion pack. See the file _ide/STM32CUBE/README.md_ for more information. (https://www.wolfssl.com/files/ide/I-CUBE-wolfSSH.pack)
• Improved test coverage for wolfSSHd.
• X.509 style private key support.

Fixes

• Fixed shadow password checking in wolfSSHd.
• Building cleanups: warnings, types, 32-bit.
• SFTP fixes for large files.
• Testing and fixes with SFTP and LwIP.

Vulnerabilities

• wolfSSHd would allow users without passwords to log in with any password. This is fixed as of this version. The return value of crypt() was not correctly checked. This issue was introduced in v1.4.11 and only affects wolfSSHd when using the default authentication callback provided with wolfSSHd. Anyone using wolfSSHd should upgrade to v1.4.13.

For any questions about using wolfSSH contact us at facts@wolfssl.com. wolfSSH is lovingly crafted by wolfSSL Inc in the Pacific Northwest.

 

wolfSSH offers all the functionality of a SSH server and client in a compact and microcontroller friendly library and is now available for use as an STM32Cube Package. wolfCrypt, the crypto engine for wolfSSH, heavily supports STM32 hardware and now you can leverage wolfSSH as an SSH solution in the same environment. wolfSSH supports SSH protocol v.2 with both password and public key based authentication and is the easiest way to implement SFTP and SCP on embedded targets, giving the possibility to customize the actions associated with remote filesystem access operations.

Download the new STM32Cube Pack from https://www.wolfssl.com/files/ide/I-CUBE-wolfSSH.pack and follow the documentation here to get started.

You can also reference this webinar for more insight on running wolfSSL on STM32 hardware. How to use wolfSSL software expansion for STM32Cube

Contact us at facts@wolfssl.com with any questions, comments or suggestions.

wolfSSL uses mutexes for most locking synchronization. In release 5.6.0 we have added support for pthread_rwlock_t (https://github.com/wolfSSL/wolfssl/pull/5952 and https://github.com/wolfSSL/wolfssl/pull/6086). It is currently implemented in the session caching logic. This will speed up multi-threaded servers by allowing multiple threads to read from the cache simultaneously. We also recommend multi-threaded servers to define ENABLE_SESSION_CACHE_ROW_LOCK when building wolfSSL. This will initialize and use a separate lock for each row in the cache.

If you have questions about optimizing wolfSSL please contact us at facts@wolfssl.com.