Things You Need To Know About OpenSSL 1.1.1

New version of the Transport Layer Security protocol TLS v1.3.

TLS v1.3 was finalized as RFC8446, it has numerous improvements over its predecessors, including a new handshake and revamped cipher suites. Some of the benefits of TLS v1.3 include:

1. Reduces number of round trips required between the client and server in the TLS 1.3 handshake versus TLS 1.2.
2. Offers 1-RTT mode and Zero Round Trip Resumption. This feature allows for near-instantaneous session resumption for visitors who have recently visited your site.
3. In certain cases, clients can start sending encrypted data to the server immediately without going back and forth with the server.
4. Enhances security by eliminating various outdated and insecure cryptographic algorithms and encrypting more connection handshakes.

For Universe 11.3.2, TLS v1.3 can be enabled by changing parameter SSL_PROTOCOLS in the uvconfig file. We also recommend using the strongest protocol supported by both client and server. However, some of our client tools do not include the latest version to support OpenSSL 1.1.1, such as wIntegrate and U2ODBC, so the maximum version used by default is still TLS v1.2. We will be adding support for TLSv1.3 to our tools and clients in future releases.

For example, if you are using the BASIC CallHTTP to verify the new protocol TLS1.3, you need to manually add the TLS v1.3 version to the uvconfig file.

Here’s how to do that: Connect to a Web site (https://github.com) using the TLS v1.3 protocol.

Confirm/check the OpenSSL information by enabling protocolLogging.

It is worth emphasizing that, we negotiate the highest protocol available within the allowed range to both SSL client and SSL server, which may not be TLSv1.3 in many cases at this point.

Simplified Cipher Suites

In TLS v1.3, cipher suites no longer include the key exchange and signature algorithms.

With TLS v1.3, the cipher suites only include the bulk cipher and the hashing algorithm. Here are the recommended cipher suites for TLS v1.3:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

To see a full list of the available ciphers, open a command prompt and navigate to the UniData or UniVerse bin directory. Enter the following command:

> openssl ciphers -v

You can use the BASIC security API setCipherSuite/getCipherSuite to manage a cipher suite for TLS v1.3. For example:

Support for various new cryptographic algorithms.

UniVerse supports a variety of new cryptographic algorithms, such as SHA3, SHA512/224 and SHA512/256 and so forth. SHA-3 (Secure Hash Algorithm 3) is the newest member of the Secure Hash Algorithm family of standards. SHA-3 is internally different from the MD5-like structure of SHA-1 and SHA-2. SHA3 includes: SHA3-224, SHA3-256, SHA3-384, SHA3-512. We can use these new algorithms to perform certain operations, such as creating a certificate or generating a message digest by using BASIC security APIs.

Customer can upgrade OpenSSL on their own to a minor version in the future.

Starting at Universe 11.3.2 (and later at UniData 8.2.2), upgrading OpenSSL is more flexible and easier than before. To upgrade to a newer minor version of OpenSSL, for instance, from OpenSSL 1.1.1b to OpenSSL 1.1.1c, we give you several options to upgrade OpenSSL on your own, without needing to change data server code. Specifically:

Option 1: Set an environment variable($USE_SSL_PATH) to specify the path.

e.g.
>setenv USE_SSL_PATH /home/cjiang/custpath_env
>env
UVHOME=/nome4/uv113
UVBIN=/nome3/uvuddb-uv113/src/uvhome/x64debug/bin
USE_SSL_PATH=/home/cjiang/custpath_env
...

Option2: Set the path into a fixed file under $UVHOME.

e.g.
> cd $UVHOME
> cat SSL_VERSION_PATH
/nome4/uv113/custpath_env

Option3: Default settings

If both option1 and option2 are set at the same time, option1 will be used and option2 will be ignored, and if both of option1 and option2 are not set, we will use the default release version.

New command for displaying the version of OpenSSL currently used by UniVerse.

e.g. TCL command “CONFIG ALL” and diagnostic tool “smat -o” or “analyze.shm -o”
NOTE: This new feature supports all the operating systems except AIX, since its shared library supports overhaul. Due to the “natural” way AIX handles shared libraries-collecting shared objects of different versions and bitness in one common archive (i.e. a libcrypto.a containing libcrypto.so.1.0, libcrypto.so.1.1, libcrypto.so.1.2-when you upgrade the minor version of OpenSSL on AIX, you can directly replace the new version of OpenSSL-three files: libcrypto.a, libssl.a, openssl in the server path $UVHOME/bin or $UDTHOME/bin). We will load the latest OpenSSL libraries from the archive file for server-side use.

Methods of building OpenSSL on different platforms.

Starting at Universe 11.3.2 and UniData 8.2.2, when compared to the previous version of OpenSSL such as 1.0.2/1.0.1, here are the changes to build OpenSSL 1.1.1.

1. For OpenSSL’s application (the ‘openssl’ command), we use dynamic links instead of static links. We use the OpenSSL default way to dynamically link the executable, making it easy to compile UniVerse and UniData openssl. Because the old way is too complex, we must call our own compilation script, at the same time. In some special cases, we found that there was an issue with the OpenSSL by the static link. On AIX only, if we set the environment variable OPENSSL_FIPS=1, then the OpenSSL executable included with UniData generated an error.
2. Use the default OpenSSL Shared libraries name. We use the original OpenSSL naming rules and have the major OpenSSL version number as part of the file name i.e., for OpenSSL 1.1.x, shared libraries are named libcrypto.so.1.1 and libssl.so.1.1.
3. Use $ORIGIN to specify the runtime shared library search path for OpenSSL. For OpenSSL’s application (the ‘openssl’ command), it doesn’t set the runtime shared library search path by default. It’s therefore advisable to set it explicitly when we build it. When we do the configuration, we use the special variable “$ORIGIN”. “$ORIGIN” in an rpath specification means the directory contains the application executable. Thus, an application located in somedir/app could be compiled with gcc -Wl,-rpath,\’\$\$ORIGIN\’ so that it finds an associated shared library in somedir/app no matter where somedir is located in the directory hierarchy.

For example:

Windows Platform do configure
> perl Configure VC-WIN64A no-rc5 no-idea no-mdc2 no-asm

Linux Platform do configure
>./config no-mdc2 no-rc5 no-idea no-asm LDFLAGS=-Wl,-rpath,\'\$\$ORIGIN\'
nssl version -a

Solaris Platform do configure
>./Configure -R \'\$\$ORIGIN\' solaris64-sparcv9-cc no-mdc2 no-rc5 no-idea no-asm

HP Platform do configure
>./config -Wl,+b,\'\$\$ORIGIN\' no-mdc2 no-rc5 no-idea no-asm shared

Note: AIX doesn’t support $ORIGIN, so we will set the rpath to /.uvlibs in the same way as other libraries like libodbc.so and libuniverse.so. Make sure UniVerse/UniData loads our shared libraries.

>./Configure -Wl,-R,/.uvlibs aix64-cc no-mdc2 no-rc5 no-idea no-asm shared

For detailed compilation methods, you can refer to our documentation.