The Future of OpenSSL On NonStop: Changes Coming

This article follows the release of the newest version of OpenSSL, 3.4. Possibly the most significant bit of news is that this will be the first release on NonStop that will support Kernel Level Threads (KLT). In this discussion, we will go into what has been happening with OpenSSL in its various forms, including NonStop SSL, SSL Toolkit, and OpenSSL itself, which is the code base for the first two products. ITUGLIB maintains and contributes to the standard OpenSSL project’s code base. For the rest of the article, TLS will be used to refer to the protocols, while the individual product names will be used when explicitly discussed. When referring to OpenSSL, this will mean the general code base while ITUGLIB OpenSSL will mean builds packaged and distributed by ITUGLIB on our website.

While it may seem obvious, OpenSSL, in one of its forms, is used widely across the NonStop community. It manages website certificates and encryption for NS HTTPD (based on Apache Web Server). Some customers use OpenSSL for terminal communication, POS device verification, and access to git enterprise servers. Many vendors’ products contain OpenSSL code, but configuration of that is not typically managed by the customers.

OpenSSL Project Versions

OpenSSL has had many versions since ITUGLIB was involved. They are described here:

NonStop SSL is a Guardian-based product that allows clients and servers in the Guardian space to interact over SSL/TLS. This product has not been maintained on J-series beyond 1.1.1d but has fixes on L-series through 3.0.14, as of this publication. A proxy in Guardian allows OSS programs to talk over TLS in an unthreaded manner.

The SSL Toolkit (T2813) is a fork of the OpenSSL project maintained by the NonStop Development team. It is currently at the 3.0.14 release and includes a build for 1.1.1w. The L-series package includes a Guardian DLL and can replace NonStop SSL in most situations.

The ITUGLIB OpenSSL package is a direct build of the standard OpenSSL project code without change. The builds include the 3.0, 3.1, 3.2, 3.3, and 3.4 series versions. The ITUGLIB OpenSSL package also uses the x86 hardware randomizer on L-series and provides FIPS compatibility – as a result, these builds should be used when the highest level of security is required. Customers can arrange for FIPS certification through appropriate government agencies.

The SSL Toolkit 3 and ITUGLIB OpenSSL 3.0.x series are binary compatible for applications needing TLS services, excluding FIPS support, which is only in the ITUGLIB builds.

OpenSSL Release Plans

The OpenSSL Team has announced an expectation that there will be two release series every year. This roughly means one in the Northern Hemisphere Spring and one in the Northern Hemisphere Fall, typically September.

Long Term Support (LTS) releases usually start from a September release and run five (5) years, although that is subject to change. When a release is designated as LTS, the OpenSSL team also publishes the end-of-life date for that release and sometimes confirms or extends the support date of other releases. For example, the 3.0.x series was somewhat delayed, which slightly pushed back support dates for other releases.

No release beyond 3.5 has been officially announced by the OpenSSL team, with 3.5 being a possible LTS release, but that has not been confirmed.

Fix Release Plans

The OpenSSL team has primary responsibility for fixing reported Common Vulnerabilities and Exposures (CVEs). These fixes, particularly critical ones, often direct the timing and frequency of fix releases, like 3.0.14. It is crucial to stay up to date with fixes for CVEs that may impact your environment.

TLS Versions

Like OpenSSL, Transport Layer Security (TLS) has had many protocol versions supported by OpenSSL and other SSL implementations. When looking at communication compatibility, ensure that you have the same set of TLS version support:

In order to be considered PCI compliant, TLS 1.0 and 1.1 cannot be used. Those two versions, and the SSL 2.0 and 3.0 TLS versions should not be used even if you do not require PCI compliance, based on vulnerabilities in the protocol versions.

TLS Futures

The OpenSSL project team has made a statement that TLS 1.0 and 1.1 are deprecated and will not be included, by default, in future builds of the 3.5.x and beyond series. Their plan is to allow optional inclusion of TLS 1.0 and 1.1 using switches when the OpenSSL software is configured. Turning on TLS 1.0 or 1.1 will not be possible at run-time. They also announced that the release following OpenSSL 3.5.x, whatever it is called, will not contain any code to enable TLS 1.0 or 1.1.

Be strongly cautioned that many companies, including SAP, have taken a position that they will not support interacting with communication infrastructure providing TLS 1.0 or 1.1 services at some future date, even if those services are not used.

As of the publication of this article, ITUGLIB does not know what HPE plans to do in the SSL Toolkit 3 to manage this situation. It would be prudent to discuss the matter with your sales representative.

ITUGLIB Plans for TLS

ITUGLIB plans to follow the OpenSSL direction and not build for TLS 1.0 or 1.1 as of the 3.5.x series, unless there is a strong need from the community. Even so, customers will be able to do their own builds of 3.5.x to enable TLS 1.0 or 1.1 at compile time.

If you have a specific need for TLS 1.0 or 1.1, please communicate that request to the ITUGLIB Team via the ‘ITUGLIB from Connect Worldwide’ LinkedIn group. (If you require privacy, contact us via info@connect-community.org.)

Depending on the number of exceptions, we may include the old protocols in builds for the 3.5.x series, or we may provide documentation on how to build OpenSSL with these protocols on your own.

If we do not hear from you, we will assume that you agree with our plans moving forward.

J-Series Plans

As far as ITUGLIB’s plans go, J-Series is expected to be at end of support at the end of 2025. This will mean that our access to a J-Series build system will disappear and we will be unable to build or deploy any OpenSSL fixes beyond that date.

Products using OpenSSL in OSS

There are many products that use OpenSSL builds in OSS. These typically can use either the SSL Toolkit 3 (T2813) or OpenSSL 3.0.x interchangeably:

• Curl exists both in the T1204 package from HPE and from ITUGLIB builds. The ITUGLIB curl builds are generally more up to date with curl releases and has more options for which OpenSSL version is used. The package is frequently updated by the curl team.
• Rsync is packaged by ITUGLIB similarly to curl, with builds for many OpenSSL versions.
• Wget is also packaged by ITUGLIB for many OpenSSL versions. This product may become incorporated into curl in the near future.
• Git is packaged by ITUGLIB and uses OpenSSL directly as well as indirectly through libcurl, which is embedded in git.

If you want to maintain compatibility between NonStop SSL (L-series), SSL Toolkit 3, and OpenSSL, you should stick with the 3.0.x release series. This may change in future, as the LTS date for 3.0.x comes closer.

Support for OpenSSL Packages

There are many ways to get support for the packages you use. If you are using a solution with an embedded OpenSSL implementation, you should initially contact the vendor of that solution. For NonStop-specific problems in ITUGLIB builds, get to us via the LinkedIn group or Connect email above. For general OpenSSL support, contact the OpenSSL team at their GitHub site (https://github.com/openssl) or via their website at https://openssl.org. For SSL Toolkit and NS HTTPD support, contact the NonStop Support Center team (GNSC).

If you require support for older releases listed above having for-fee extended support available, contact the ITUGLIB team to discuss making that happen.

Most importantly, keep all of your subsystems up to date with security fixes, regardless of their source. This includes your RVUs, OSS environment, especially including independent products.

Conclusion

Business today is done online, which is a medium that needs to be protected using industry-standard encryption. For decades, OpenSSL has made this accessible to multiple platforms, and ITUGLIB and HPE have brought this to NonStop. Your ITUGLIB team continues to keep the latest security, and usability features available to you.

We do understand that OpenSSL has potentially made your security environment more complex by increasing the speed at which releases are made, but it is important to stay up to date as much as possible. We strongly urge you to please participate in the conversation with ITUGLIB and with HPE so we, as a community, can continue to optimize critical security offerings.