Making Your Application More Secure with UniVerse 11.3.1 and UniData 8.2

March 1, 2017

Information systems security is high on the task list of today’s IT professionals. With your enterprise’s business on the line, securing your applications and servers is not a task to be taken lightly. If you’re running an application based on the UniVerse or UniData application platform, then you have a set of security features and tools that can help you achieve your application and data security goals.

To secure your data-at-rest, you can use U2 Automatic Data Encryption (ADE) or BASIC security APIs, which protects data in hashed data files saved on disks. To secure your data-in-motion, you can turn on SSL support, which protects data moving between your servers and U2 clients (such as telnet, ODBC, OLEDB, .NET, JDBC or UniObjects), or between U2 sessions and third party web servers (using socket or CallHTTP clients).

As the security landscape continues to change, new threats and vulnerabilities are observed on a daily basis. In concert, Rocket has also been enhancing the security features of UniVerse and UniData.

With the release of UniVerse 11.3.1 and UniData 8.2.0, we provide several noticeable enhancements that you may want to look into in more depth. In these releases, you’ll benefit from:

• FIPS 140-2 support
• Numerous security vulnerability fixes
• Strengthened SSL protocol version support
• A newer version of OpenSSL library (1.0.2h)
• An updated Root Certificate Store which contains more and updated public CA certificates to help your SSL-based applications connect to third party servers

In this article, we concentrate on OpenSSL-related enhancements.

FIPS 140-2 Support

The Federal Information Processing Standard (FIPS) refers to a set of US federal government standards that direct the adoption and procurement of information technology and products. In particular, FIPS 140-2 (or FIPS PUB 140-2) is a standard used to accredit cryptographic modules used in a software or hardware product. FIPS 140-2 support is essential for a product to be eligible for procurement by US federal government agencies. It is also increasingly being adopted by local governments and even some private industries.

We are happy to say that with UniVerse 11.3.1 and UniData 8.2.0, our customers can confidently build software that are capable of meeting the FIPS 140-2 requirement.

Before we get into the details of how we turn FIPS 140-2 support on or off in U2 and evaluate its impact, we need to clarify what we mean by “FIPS 140-2 support”. A full discussion is beyond the scope of this short article. Users should consult their auditor for an ultimate determination. The following links may prove useful information on this subject:

https://www.openssl.org/docs/fipsnotes.html

http://openssl.org/docs/fips/UserGuide-2.0.pdf (specifically, section 5.5)

Simply speaking, there is a fundamental difference between software that is “FIPS 140-2 validated/verified/compliant” and software that “provides FIPS 140-2 support”. To claim the former, the software must go through the vigorous validation procedure authorized by the National Institute of Standards and Technology (NIST). U2 has not and will not “validate” its software to be FIPS 140-2 “compliant” because this is up to the business that is being held to this standard. However, as the above OpenSSL links have explained, if a software performs all its cryptographical operations through a FIPS 140-2 validated module, then by all practical purposes, the software can say it supports FIPS 140-2,” or it is “FIPS-capable,” which is the case for U2. In UniVerse 11.3.1 and UniData 8.2.0, we use the OpenSSL FIPS Object Module 2.0.11, which is an NIST-certified FIPS module, to perform all cryptographical operations, including those required by ADE and SSL, if so configured.

Now let’s get past the legal jungle and see how the FIPS 140-2 mode is used in U2.

There is a new configuration parameter, FIPS_MODE, in uvconfig and udtconfig. By default, its value is 0, meaning the FIPS mode is turned off. If your software does not need to satisfy FIPS 140-2, by all means you can leave the value as is and skip to the next section, OpenSSL 1.0.2h.

If you change the value to 1 and restart your system, then FIPS mode is on for all new sessions. The consequence of turning on the FIPS mode can be simply summarized as follows: only a small subset of encryption and digest algorithms supported by OpenSSL can be used in FIPS mode, namely, Triple-DES, AES, SHA1, and SHA2 families and some other lesser-used algorithms.

This impact could pose some challenges to some users.

If you have been using non-FIPS encryption algorithms in the past, you must re-encrypt your data in non-FIPS mode before you can turn the FIPS mode on and access your data. For example, if you have encrypted an ADE file using RC4 or DES, you must decrypt and re-encrypt it (you can run REENCRYPT.FILE to perform this task in one pass). For users who have multiple ADE files scattered in many different places, you can use a new encman utility option listADEfiles to find out all offending algorithms:

encman –listADEfiles [-non-FIPS-only] <file-path>

If you have used non-FIPS digest algorithms (such as MD5) and stored the result somewhere, you will probably have to recalculate and re-save the digest values using a FIPS-compliant algorithm, such as SHA256 or SHA512.

Moreover, some of the U2 internal security-related objects use non-FIPS compliant algorithms (they were developed more than a decade ago prior to FIPS-140). Years ago we changed the internal algorithms to FIPS compliant algorithms. But if you have been using SSL for a long time and never changed your SCRs or SPLs (on the client side), chances are they were created using non-FIPS algorithms. We can handle objects saved using the old or new algorithms transparently in non-FIPS mode sessions. To be able to use them in FIPS mode, they must be re-saved. You must do the re-save in non-FIPS mode sessions – or U2 cannot decipher them. For SCRs, you can write a BASIC program using loadSecurityContext() and saveSecurityContext(), or use XAdmin to load and save. For SPLs, you can use the client-side SSL Config Editor to do the load and save. Once they are re-saved, you can turn FIPS mode on and use them in your application.

In even rarer cases, some EDA or Replication-created internal credential objects must be recreated if you want to run in FIPS mode.

For SSL applications, FIPS mode can be effectively enforced on the server side. Namely, if you turn FIPS mode on, on the server, you can guarantee that no non-FIPS algorithms will be negotiated by the peers. However, in case your auditor is asking you to turn FIPS mode on, on the client side, you can set the FIPS_MODE value in the Windows registry. For more detail, please refer to the Security Features manual.

You can turn FIPS mode on or off on a per-session basis, using the following command:

SET.FIPE.MODE [ON | OFF]

If you want see the current FIPS setting, run:

GET.FIPS.MODE

or

SET.FIPS.MODE INFORM

A session’s FIPS mode is passed into any child processes (such as a phantom child). Of course the child process can change its FIPS mode setting without ever affecting its parent.

OpenSSL 1.0.2h

In UniVerse and UniData, all crypto operations are performed through the open source OpenSSL library. From time to time, OpenSSL releases upgrade versions, which fix vulnerabilities and enhance features. Rocket U2 evaluates each and every such new release. When the fixed vulnerabilities are determined to have impact on U2 users, we rebuild and distribute the new OpenSSL library.

Since UniVerse 11.2 and UniData 8.1, we have improved our OpenSSL updatability. Previously (with OpenSSL 0.9.7e), you had to install a new UniVerse or UniData release to be able to get the new OpenSSL library. Now with UniVerse 11.3.1 and UniData 8.2.0, you can obtain our new OpenSSL library (two files) and simply put them into $UVHOME/bin or $UDTHOME/bin. To ensure all sessions are using the new OpenSSL library, it is recommended that you restart your system after such an upgrade.

To check the version of your Rocket-built OpenSSL library, run the following command:

$UVHOME/bin/openssl version –a

Or

$UDTHOME/bin/openssl version –a

You should see something similar to the display below:

OpenSSL 1.0.2h-fips  3 May 2016

built by: Rocket Software, Inc. BuildNumber: 10281

built on: Mon May  9 11:07:46 2016

platform: linux-x86_64

options:  bn(64,64) rc4(ptr,int) des(idx,cisc,16,int) blowfish(idx)

compiler: gcc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -O3 -Wall -I/usr/local/ssl/fips-2.0/include OPENSSLDIR: “/usr/local/ssl”

Note that on some systems, it is possible that there are multiple OpenSSL libraries installed with OS or other third-party software. It is essential that you check OpenSSL with the right path, illustrated above. The Rocket-built OpenSSL library has U2-specific debugging hooks built into it, which can help identify SSL and crypto-related application problems. Stock build OpenSSL by OS or any third-party cannot be used with UniVerse and UniData. Rocket can now issue modular OpenSSL updates in the form of “HotFixes” for UniVerse and UniData on a situational basis to patch vulnerabilities in OpenSSL as they become known and fixed.

The previous OpenSSL library version we shipped with UniData 8.1.2 was 1.0.1q, and for UniVerse 11.2.5 was 1.0.1m.  Both of these OpenSSL versions were released in the first half of 2015. OpenSSL has announced that they will end official support (i.e. vulnerability fixes) of the 1.0.1 series by the end of 2016. Facing this change, we decided to upgrade our OpenSSL library to 1.0.2h, released in May 2016. The Rocket-built OpenSSL 1.0.2h library contains the OpenSSL FIPS Object Module 2.0.11, and is capable of running in both non-FIPS and FIPS modes. This library can also be used with any UniVerse or UniData releases that have OpenSSL 1.0.1c and above – although the FIPS support cannot be turned on by earlier UniVerse or UniData releases.

If you are still on earlier UniVerse or UniData versions which use OpenSSL 0.9.7e, it is imperative to upgrade to later releases since the 0.9.7e library is utterly obsolete and contains unfixable security vulnerabilities that will likely harm your enterprise business.

SSL Protocols and Options Configuration

Since the advent of the first SSL protocol, SSLv.2, almost two decades ago, the protocols have gone through tremendous changes. On one hand, SSL has enjoyed world-wide adoption as the de facto web security protocol. On the other hand, severe and fatal protocol and implementation flaws have been found, exploited and fixed, and the protocols have gone through constant enhancements, from SSLv3, to TLSv1, TLSv1.1 and TLSv1.2. TLSv1.3 and TLSv2.0 are still being developed as of this publication.

Particularly, in the last three years we saw explosions of SSL-related vulnerabilities. The most notorious ones are all coined into horrifying names such as Heartbleed, POODLE, FREAK, BREACH, CRIME, DROWN, LOGJAM and OprahSSL and the list goes on. Most of these vulnerabilities were the result of fundamental protocol design flaws or implementation induced ones. Most of them can be mitigated by turning off older protocols by default and configuring the system to disable automatic downgrades. Some require upgrading to a newer OpenSSL library.

The industry consensus of years ago was that you should never use SSLv2. Now SSLv3 has been added to this list. Some popular browsers have also turned off TLSv1. In practice, if TLSv1.2 is supported by all your clients and servers you have to connect to, just use TLSv1.2. Do not bother with anything lower.

UniVerse and UniData support multiple SSL protocol versions through the underlying OpenSSL library. When you create an SCR or SPL, you specify a set of desirable SSL protocol versions. During SSL handshake, the client and server will negotiate and agree on a commonly supported protocol, which in most situations should be the highest protocol supported by both.

Starting with UniVerse 11.2.5 and UniData 8.1.0, you can configure system-wide default SSL protocols and options. By default, the protocols are TLSv1, TLSv1.1 and TLSv1.2, specified by the uv(udt)config parameter SSL_PROTOCOLS. We keep the TLSv1 on the list because some customers have informed us that the servers they connect to still do not support TLSv1.1 or TLSv1.2. We believe that, over time, more and more servers will be updated to support TLSv1.2. We recommend that you verify the availability of TLSv1.2 on the servers your application must connect to. If TLSv1.2 is supported, then you should change the default to TLSv1.2 only. TLSv1 is at the end of its useful life. We want to emphasize that, under no circumstances should you turn on SSLv3. SSLv2 is not possible even if you turn it on – the underlying OpenSSL 1.0.2h does not support SSLv2.

As for protocol options, currently only one such option is supported, through the uv(udt)config parameter SSL_OPTIONS. The option is called TLS_FALLBACK_SCSV. We do not want to bother you with tedious details of what SCSV means, but suffice it to say that the purpose of this option is to tell the peer that there is a possibility of a malicious protocol downgrade attack going on so please do not connect if you know that I can support a better protocol. This advertisement will defeat the so called “Man-in-the-Middle” attacks that allow a bad guy to drop the connection to a weaker protocol, such as SSLv3, so that he can mount a POODLE-like attack.

This all sounds good – by default we (meaning UniVerse and UniData clients and servers) should always send this option to the peer they want to connect to; however, in practice, many servers that our customers connect to do not understand this option and simply drop the connection, making the customer application useless. Also, users were at a loss trying to figure out why. So, we had a painful decision to make; we decided to turn off TLS_FALLBACK_SCSV by default. That’s why if you examine your uv(udt)config file you will see SSL_OPTIONS = NO_TLS_FALLBACK_SCSV.

However, it is our belief that most, if not all, of the buggy servers should be patched by now. Therefore, as a best practice, you should turn on TLS_FALLBACK_SCSV by default. At least, it is a good test to flag buggy servers that need to be alerted to upgrade!

On a Windows system, you can also change the default SSL protocol and options setting on the client side. When you install U2 clients and tools, two registry keys, SSL_PROTOCOLS and SSL_OPTIONS, are also created under HKEY_LOCAL_MACHINE\Software\Rocket Software\UniClient, with the same default values as in the uvconfig or udtconfig file on the server side.

SSL Cipher Suite String

And if these protocols and options aren’t confusing enough for DBAs and sysadmins who are tasked with protecting their corporate assets, let’s move on to another SSL-related important configuration issue: the strength of the allowed cipher suites.

A cipher suite is composed of a key exchange algorithm (RSA, DHE, etc.), an encryption algorithm (AES, 3DES, RC4 etc.), the encryption key length (40, 128 or 256 etc.), and a hash algorithm (MD5, SHA1, SHA256 etc.). For example,

TLS_RSA_WITH_AES_128_GCM_SHA256

By default, there are several dozen cipher suites available for a particular protocol, one of which is determined by the negotiation between the communicating peers during the SSL handshake phase. Normally, it should be the strongest one supported by both sides; however, clever hackers can exploit the fact that there are lower grade suites available and they can potentially trick your software to downgrade to the weaker ones to make it easier to steal data.

To prevent this from happening, you should harden you system to disable the weaker cipher suites. It is generally agreed that all export grade suites, NULL suites, or any suites using MD5, DES or RC4 are considered weak and should be turned off.

The way to do this in UniVerse or UniData is to explicitly specify “cipher suite string” in SCRs or SPLs. You can use XAdmin (for SCRs) or SSL Config Editor (for SPLs) to specify the cipher string, or you can refer to the BASIC Extension manual for BASIC API details. The cipher string to turn off weak suites can be:

HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4 (a black list approach)

Or

EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH (a white list approach)

Another example (combined white and black list):  ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS:!RC4

You can examine a cipher string and verify that the resultant suites are what you desire by running:

$UVHOME/bin/openssl ciphers –v “<your-cipher-string>”

Please note that you should always test against all servers you connect to after changing the cipher suites to make sure the connection can be established and the negotiated ciphers are indeed strong enough to satisfy your requirement.

Summary

Rocket Software and the U2 Lab are continually enhancing the security of UniVerse and UniData. As the software and information system security landscape is constantly evolving, we will keep introducing new security features and enhancements into the product. As a business concerned with its data security in a digital world of uncertainty, it is important that you too pay attention to industry developments and best practices regarding securing enterprise systems, and adopt newer UniVerse and UniData releases in order to obtain the latest security upgrades. Particularly, Rocket will publish security alerts, Tech-notes, white papers and release new OpenSSL libraries whenever we see the need. Timely installation of the security upgrades is a best practice to safeguard your enterprise assets. Please contact us at [email protected] if you have questions about U2 data security.