Category: wolfSSH

wolfSSH Support With TPM Public Key Authentication

wolfSSH now supports TPM public key authentication with RSA. This feature enhances security for embedded and IoT applications by leveraging TPM 2.0 functionality for client side authentication. Below is a summary of the key changes that were made in PR# 754.

TPM Public Key Authentication with RSA
PR# 754 provides TPM-based RSA authentication for client-side public key operations to facilitate integration into non-TPM RSA workflows.

Benefits of Using TPM for Public Key Authentication

  1. Hardware-Backed Security
    When using public key authentication, a TPM device provides the ability to safely secure and manage private keys and cryptographic algorithms inside the TPM. Since the private key is loaded securely inside the TPM and used only from within the TPM this allows for higher security. In this case the TPM device generates and supplies a secure keyblob that holds the private and public key data. wolfSSH reads and verifies this data and formats the key in a way that can be utilized in the SSH functionality.
  2. Specialized Performance
    While maintaining the lightweight, high-performance aspects of wolfSSH and implementing TPM-based features, wolfSSL has combined the security benefits of hardware-backed key storage and SSH functionality, ensuring robust authentication without compromising efficiency or security.

Testing
To test the SSH TPM-based public key authentication, we developed a comprehensive github CI workflow that tests with and without custom keyauth. The general steps we followed where:

  1. TPM Simulator:
    Ran the TPM 2.0 server from a TPM simulator.
  2. Key Generation:
    Generated a keyblob with wolfTPM’s keygen tool, converting the public key to the SSH format using ssh-keygen.
  3. Server & Client Setup:
    Start the server and supply the base-64 encoded public key:
    `./examples/echoserver/echoserver -s key.ssh`
    Run the client with the TPM 2.0 keyblob and user supplied password:
    `./examples/client/client -i ../wolfTPM/keyblob.bin -u hansel -K ThisIsMyKeyAuth`
  4. Testing Command with Debugging:
    Used `--enable-debug` to enable debug output and verified functionality through command line debug logs.

The CI test tpm-ssh.yml validates proper operation of TPM-based public key authentication by validating outputs and testing with a custom and default keyauth. This process ensures that wolfSSH functions correctly and securely with TPM-based keys.

Conclusion
With TPM public key authentication, wolfSSH combines the best of both worlds: secure private key handling and robust SSH functionality. These changes enhance security without compromising performance, making it an ideal choice for users seeking both ease of use and advanced cryptographic protection.

For more details and steps to get started you can refer to the TPM section in the wolfSSH README. For more information or questions, contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSH 1.4.20: Enhanced Features and Stability

The wolfSSL team has released wolfSSH version 1.4.20, introducing some new features and nice fixes!

New Features:

  • DH Group 16 and HMAC-SHA2-512 Support: This addition gives more options for algorithms used when connecting and more interoperability with other implementations.
  • Keyboard-Interactive Authentication: Providing a more versatile authentication method implementing RFC 4256.

Enhancements and Fixes:

  • Memory Management Improvements: wolfSSH now handles memory more efficiently, particularly in RNG initialization and the SCP example, ensuring cleaner resource management.
  • Stability Enhancements: Updates to wolfSSHd include better handling of failures and connections, making the server more robust and reliable.
  • Resolved Issues: Fixes address SFTP compilation problems with WOLFSSH_FATFS and simplify the autogen script for easier integration.

Check out the ChangeLog for a full list of features and fixes.

Stay updated with wolfSSH for ongoing enhancements! If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

TLS vs. SSH: When To Use Which

TLS and SSH are both widely used protocols used for creating secure connections between two systems over a secure network. But, they are designed for different use cases, so today we are going to take a quick dive into when you should use which.

About TLS

TLS (Transport Layer Security) is what is most commonly used to secure connections to the web, it is the successor to SSL (Secure Sockets Layer) to which wolfSSL gets part of its name. Today, almost all websites use TLS and most web browsers expect a website to use TLS when connecting. It has other use cases, such as email and VNC.

In general, TLS is designed so that a client can authenticate that the intended web server is where the data transfer is happening, and encrypt the data in transit.

About SSH

SSH (Secure SHell) is likely well known if you have used a Linux or Unix-based system before. It is typically used to remotely log into a server and execute commands on that server, as well as transfer files. It is ideal for remote shell or desktop access to machines over an unsecured network.

In addition to our namesake product, wolfSSL, we have a product called wolfSSH, which can provide lightweight SSH client and server support for embedded platforms.

Key Differences

Authentication

SSH allows for many different authentication methods, from basic passwords to keys and certificates. TLS typically relies on a trusted CA (Certificate Authority) for the authentication. Both TLS and SSH support OCSP for certificate revocation status.

Feature Set

SSH not only handles the basic authentication and encryption, but provides the next layer of features, such as shell access, file transfer and port forwarding. TLS is typically a secure wrapper around regular plain protocols.

Another feature SSH provides is the concept of channels. This allows multiplexing of multiple services over one SHH connection. For example, a single connection can have a shell, file transfer and multiple ports forwarded simultaneously.

Performance

TLS, particularly version 1.3, has a very low number of round trips required to handshake between the client and server. Whereas the handshake for SSH is a lot more involved, this can make a new connection a lot more expensive on a high-latency network.

Once the connection is established, the performance of each should be relatively similar, depending on the encryption algorithms used.

Ease Of Use

TLS is designed to be relatively easy to use, in particular, there is a low barrier to entry for the client user. SSH can be more difficult to configure and typically has more steps for the end user due to the mutual authentication.

Summary

Both TLS and SSH are essential parts of securing traffic over untrusted networks. TLS is very useful to wrap existing protocols with a layer of security, whereas SSH is ideal for remote command access to a system and network tunnels.

If you wish to learn more or have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

What’s New in wolfSSH 1.4.19

The latest version of wolfSSH, 1.4.19, brings improvements, stability fixes and an additional feature! DH Group 14 with SHA-256 Key Exchange (KEX) support was added in with this release.

Along with this new feature some of the improvements that were added are: CI testing, macro guards around TTY modes, use of wolfSSL kyber implementation, and an update to the Espressif example. Among the fixes there were additions for gracefully handling non-existent directories with SFTP and handling of re-key/window full cases with wolfSSHd. For a full list of changes see the bundled ChangeLog.md

Contact facts@wolfSSL.com for more information regarding wolfSSL and wolfSSH.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSH with X.509 Certificates

Did you know wolfSSH can use X.509 certificates in place of SSH public keys? wolfSSH supports RFC 6187, “X.509v3 Certificates for Secure Shell Authentication”. This uses wolfSSL’s certificate management for TLS, so the certificates may be checked against CRLs and OCSP.

wolfSSH has been used in applications as a server where it needed to validate some FPKI (Federal Public Key Infrastructure) profiles. It is used with clients that authenticate the user’s credentials accessed via a card reader. wolfSSH’s client can be given an X.509 certificate to authenticate the user with the server.

If you have questions about wolfSSH, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

wolfSSH VxWorks FIPS 140-3

Do you need SSH support for an embedded device running VxWorks and do you have a FIPS 140-3 requirement? wolfSSL has what you need: wolfSSH, an embedded SSH library running on top of our wolfCrypt FIPS library, and the wolfCrypt module holds the world’s first SP800-140Br1 FIPS 140-3 Validated, Certificate #4718.

While full FIPS 140-3 support on VxWorks isn’t here yet, stay tuned! Exciting developments are on the horizon. We’re working hard to bring this capability to you in the very near future!

Interested in learning more or preparing for what’s ahead? Email us at fips@wolfSSL.com, and let’s discuss how we can help you integrate wolfSSH into your VxWorks application and guide you through the FIPS process when the time comes.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or +1 425 245 8247.

Download wolfSSL Now

Why wolfSSH is Immune to the regreSSHion

Recently, Qualys found an exploit in OpenSSH’s sshd server application that they named regreSSHion. This exploit lets attackers run arbitrary code by exploiting a race condition in a signal handler.

wolfSSH is not a port or fork of OpenSSH. It is written from scratch by wolfSSL Inc. While wolfSSHd is using the same alarm signal to time out users, our signal handler only sets a flag. OpenSSH’s handler, on the other hand, called unsafe functions.

How wolfSSH Avoids This Vulnerability

wolfSSH’s signal handling is designed to be safer due to:

  1. Minimalist Signal Handling: Our handler only sets a flag, reducing race condition risks.
  2. Async-Signal Safe Operations: We ensure all operations within the signal handler are safe.
  3. Independent Implementation: wolfSSH is a complete rewrite, avoiding inherited vulnerabilities.

Conclusion

The regreSSHion exploit in OpenSSH underscores the need for safe signal handling. wolfSSH’s simple and secure approach to signal handling avoids the vulnerabilities found in OpenSSH, making it a safer choice for SSH server applications.

If you have any questions or want to talk about wolfSSH, please feel free to send us an email at facts@wolfssl.com or sales@wolfssl.com, or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSH 1.4.18 Now Available!

It is Christmas in July! The summer release of wolfSSH is here, version 1.4.18!

Version 1.4.18 brings with it bug fixes, new features, and some enhancements as well! New features in this release include new algorithms and a memory configuration option.

We also have a nice round of enhancements which range from channel setup callbacks, better testing, improved portability, and more!

New Features

  • wolfSSL style static memory pool allocation support.
  • Ed25519 public key support.
  • Banner option for wolfSSHd configuration.
  • Non-blocking socket support to the example SCP client.

Improvements

  • Documentation updates.
  • Update the Zephyr test action.
  • Add a no-filesystem build to the Zephyr port.
  • Update the macOS test action.
  • Refactor certificate processing. Only verify certificates when a signature is present.
  • Update the Kyber test action.
  • Refactor the Curve25519 Key Agreement support.
  • Update the STM32Cube Pack.
  • Increase the memory that Zephyr uses for a heap for testing.
  • Add a macro wrapper to replace the ReadDir function.
  • Add callback hook for keying completion.
  • Add function to return strings for the names of algorithms.
  • Add asynchronous server side user authentication.
  • Add ssh-rsa (SHA-1) to the default user auth algorithm list when sha1-soft-disable is disabled.
  • Update Espressif examples using Managed Components.
  • Add SCP test case.
  • Refactor RSA sign and verify.
  • Refresh the example echoserver with updates from wolfSSHd.
  • Add callback hooks for most channel messages including open, close, success, fail, and requests.
  • Reduce the number of memory allocations SCP makes.
  • Improve wolfSSHd’s behavior on closing a connection. It closes channels and waits for the peer to close the channels.

Fixes

  • Refactor wolfSSHd service support for Windows to fix PowerShell Write-Progress.
  • Fix partial success case with public key user authentication.
  • Fix the build guards with respect to cannedKeyAlgoNames.
  • Error if unable to open the local file when doing a SCP send.
  • Fix some IPv6 related build issues.
  • Add better checks for SCP error returns for closed channels.
  • In the example SCP client, move the public key check context after the WOLFSSH object is created.
  • Fix error reporting for wolfSSH_SFTP_STAT.
  • In the example SCP client, fix error code checking on shutdown.
  • Change return from wolfSSH_shutdown() to WS_CHANNEL_CLOSED.
  • Fix SFTP symlink handling.
  • Fix variable initialization warnings for Zephyr builds.
  • Fix wolfSSHd case of non-console output handles.
  • Fix testsuite for single threaded builds. Add single threaded test action.
  • Fix wolfSSHd shutting down on fcntl() failure.
  • Fix wolfSSHd on Windows handling virtual terminal sequences using exec commands.
  • Fix possible null dereference when matching MAC algos during key exchange.

Visit our download page to download the release bundle, or clone it from GitHub. Feel free to email us at facts@wolfssl.com or support@wolfssl.com or call us at +1 425 245 8247 with any questions about the wolfSSH embedded SSH library or other products.

Download wolfSSL Now

Vulnerability Disclosure: wolfSSH (CVE-2024-2873)

Affected Users:

Anyone using wolfSSH server versions prior to release v1.4.17.

Summary:

It is possible for a malicious client to bypass user authentication when logging into a wolfSSH server. The wolfSSH server was not rigorous about checking the current state of the key exchange when handling channel open messages.

wolfSSH’s example echoserver and the wolfSSHd server will not allow one to obtain a shell as root or any other user. By skipping the user authentication, the user’s login name won’t be set, and the server will error out because it cannot find the user’s home directory. At this point, the server has allocated some memory resources for a channel, but then releases them immediately.

Due to the way wolfSSH server handles incoming connections, forwarding requires an active shell connection to work. If user authentication is skipped, the server will terminate the connection with an error before allowing any forwarding.

This issue with message processing is in the library. The application using the library has the responsibility of checking that the username is set and checking the credentials. One could have an application that gives access to the system without checking the user authentication.

Recommendation:

Prompt update to wolfSSH v1.4.17. This version rejects out-of-sequence channel messages before user authentication has completed and rejects user authentication messages after user authentication is complete.

Additional Details:

The patch fixing this issue can be viewed at the links:

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSH, SHA-1, and Configuration

wolfSSH is following the industry common practice of removing SHA-1 as a default configuration option. SHA-1 has been considered broken for a while now and shouldn’t be used for security purposes. [RFC 8332](https://datatracker.ietf.org/doc/html/rfc8332) recognizes this for the SSH protocol and offers new RSA-based algorithms for signing authentication messages.

In the wolfSSH v1.4.15 release, we were heavy-handed when it came to disabling SHA-1 and removed it from the compile using a preprocessor flag. There was an option to add it back in, but its use wasn’t clear. This was a mistake.

For wolfSSH v1.4.17, we restored SHA-1 to the library, but it is “soft-disabled.” This means it is not offered in the default list of algorithms available during key exchange. One may add the algorithm “ssh-rsa” back as an available algorithm, along with DHE using SHA-1, at runtime. To support this, there is now a set of functions to set the algorithm lists used during key exchange and to poll the library on which algorithms are enabled in the build. Please see the wolfSSH manual section 13 for more information on the [Key Exchange Algorithm Configuration].

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2