Moving to TLS 1.2 is not enough to keep your data secure.

I was at the COMMON Fall Conference in Columbus, Ohio, two weeks ago where I (among other things) presented two sessions on IBM i systems management. One of the sessions was called "IBM i and our False Sense of Security." It was essentially a mixture of a number of security-related articles I’ve been writing as of late.

The good news was that the session was absolutely packed. The bad news is that ciphers and encryption in general were subjects not well known to the audience in my session. That’s not a bad thing actually. It showed the necessity and relevance of the session’s content. It also showed that people are looking to modernize their security. Part of the session was built from another article I wrote this year entitled “Modernization of IBM i Security” in which I went in depth about ciphers and the different default values you get with IBM i 6.1, 7.1, and 7.2. With the release of IBM i 7.3, there’s some really good news on the encryption front, which I’ve added to my slides but also needed to share with you as an add-on article.

In the first article, I outlined the default ciphers loaded in each operating system release. The ciphers in this list are controlled by the QSSLCSL system value. They are outlined below with the exception of IBM i 6.1, which is no longer supported. The bold items have been deemed broken, weak, and insecure.

IBM i 7.1

*RSA_AES_128_CBC_SHA

*RSA_AES_128_CBC_SHA256 (requires TR6 or later installed and *TLSv1.2 enabled)

*RSA_AES_256_CBC_SHA

*RSA_AES_256_CBC_SHA256 (requires TR6 or later installed and *TLSv1.2 enabled)

*RSA_3DES_EDE_CBC_SHA

*RSA_3DES_EDE_CBC_MD5

*RSA_DES_CBC_SHA

*RSA_EXPORT_RC4_40_MD5

*RSA_EXPORT_RC2_CBC_40_MD5

*RSA_NULL_SHA

*RSA_NULL_MD5

*RSA_NULL_SHA256

*RSA_RC2_CBC_128_MD5

*RSA_DES_CBC_MD5

*RSA_RC4_128_SHA

*RSA_RC4_128_MD5

IBM i 7.2

*ECDHE_ECDSA_AES_128_CBC_SHA256

*ECDHE_ECDSA_AES_256_CBC_SHA384

*ECDHE_ECDSA_AES_128_GCM_SHA256

*ECDHE_ECDSA_AES_256_GCM_SHA384

*RSA_AES_128_CBC_SHA256

*RSA_AES_128_CBC_SHA

*RSA_AES_256_CBC_SHA256

*RSA_AES_256_CBC_SHA

*RSA_AES_128_GCM_SHA256

*RSA_AES_256_GCM_SHA384

*ECDHE_RSA_AES_128_CBC_SHA256

*ECDHE_RSA_AES_256_CBC_SHA384

*ECDHE_RSA_AES_128_GCM_SHA256

*ECDHE_RSA_AES_256_GCM_SHA384

*ECDHE_ECDSA_3DES_EDE_CBC_SHA

*ECDHE_RSA_3DES_EDE_CBC_SHA

*RSA_3DES_EDE_CBC_SHA

*ECDHE_ECDSA_RC4_128_SHA

*ECDHE_RSA_RC4_128_SHA

*RSA_RC4_128_SHA

*RSA_RC4_128_MD5

*RSA_DES_CBC_SHA

*RSA_EXPORT_RC4_40_MD5

*RSA_EXPORT_RC2_CBC_40_MD5

*ECDHE_ECDSA_NULL_SHA

*ECDHE_RSA_NULL_SHA

*RSA_NULL_SHA256

*RSA_NULL_SHA

*RSA_NULL_MD5

As you can see, IBM i 7.1 and 7.2 have many ciphers loaded by default that are not secure. Approximately 70 percent of the ciphers in 7.1 are weak. If you are on 7.1 Technology Refresh 6 and have manually added RSA_AES_128_CBC_SHA256 and RSA_AES_256_CBC_SHA256 to the list, then you’ve moved the needle to 63 percent insecure. You also had to change the QSSLCSLCTL (Secure Sockets Layer Cipher Control) system value from *OPSYS (operating system controlled) to *USRDEF (user defined) in order to make that change. That’s pretty alarming stuff.

IBM i 7.2 is much more secure, with 43 percent of the ciphers being insecure. This is due to the addition of the 12 elliptical curve ECDHE ciphers added to the operating system. Note that although 12 were added, only 10 are deemed secure. The old ciphers still exist on that list.

On 7.3, it becomes much more secure, but with a couple of caveats.

*ECDHE_ECDSA_AES_128_GCM_SHA256

*ECDHE_ECDSA_AES_256_GCM_SHA384

*ECDHE_RSA_AES_128_GCM_SHA256

*ECDHE_RSA_AES_256_GCM_SHA384

*RSA_AES_128_GCM_SHA256      

*RSA_AES_256_GCM_SHA384      

*ECDHE_ECDSA_AES_128_CBC_SHA256

*ECDHE_ECDSA_AES_256_CBC_SHA384

*ECDHE_RSA_AES_128_CBC_SHA256

*ECDHE_RSA_AES_256_CBC_SHA384

*RSA_AES_128_CBC_SHA256    

*RSA_AES_128_CBC_SHA        

*RSA_AES_256_CBC_SHA256    

*RSA_AES_256_CBC_SHA        

*ECDHE_ECDSA_3DES_EDE_CBC_SHA

*ECDHE_RSA_3DES_EDE_CBC_SHA

*RSA_3DES_EDE_CBC_SHA      

Each of these ciphers is loaded by default and is deemed secure. IBM has removed the older, insecure ciphers from the default list in 7.3. That’s good news for you. In fact, to keep up to date with IBM’s recommendations you should bookmark the following Technote. I agree with most of the content; however, we have a difference of opinion about whether TLS 1.0 is secure. It’s not, at least according to PCI compliance plans.

The caveat is that if you’ve edited the QSSLCSLCTL system value to *USRDEF in the past and manually specified what ciphers you wanted as part of the QSSLCSL system value, then those entries are in the list once you move to 7.3. The old ciphers are not the default any longer, but they’re still supported. That means if you’ve upgraded to 7.3 from 7.1, then you’re not taking advantage of the new ECDHE ciphers and it’s possible you’re using older, deprecated ones. Maybe you had to leave a broken cipher in place in 7.1 because an application required it at that release. Now the application will accept an old cipher plus the new ciphers but you’re still using the old.

In order to rectify this situation, when you move to 7.3, you can set the QSSLCSLCTL value back to *OPSYS and it will load only the default values for 7.3. When ciphers become obsolete, you can then change that system value back to *USRDEF and remove them manually from the list.

Sounds like a lot of work, doesn’t it? Ciphers can be daunting at first. But if we’re running secure applications, then we’re going to have to keep an eye on them because they do get broken and new ciphers do get added.

7.2 and 7.3 have also tightened things up on the Secure Sockets Layer (SSL) versus Transport Layer Security (TLS) protocol front. In 7.1, support for TLS 1.2 was only added in Technology Refresh 6, so it’s not turned on by default. You need to switch it on using the Secure Sockets Layer Protocols (QSSLPCL) system value. The default values for QSSLPCL are SSLv3 and TLS 1.0, both deemed weak in comparison to TLS 1.1 and 1.2.

In 7.2 and 7.3, IBM has ensured that only TLS 1.0, 1.1 and 1.2 are loaded by default in QSSLPCL. If you move to 7.3, you’ll notice that if you haven’t specified any values manually in QSSLPCL, the default value will be *OPSYS (i.e., values *tlsv1, *tlsv1.1, and *tlsv1.2). If you have specified it manually, you need to make sure that you don’t have *sslv2 or *sslv3 in there, because they’re still supported although highly insecure. In fact, I personally would change this from *OPSYS and manually specify only *tlsv1.1 and *tlsv1.2 because they’re the only really secure protocols. And if you are bound by PCI requirements, TLS 1.1 and 1.2 will soon be the standard you must abide by.

Depending on what protocols you use, you end up lopping off support for certain ciphers, which makes the really insecure ones a moot point to worry about. The ciphers that work over many protocols are the ones you need to worry about. For instance, take a look at the following ciphers:

*RSA_RC4_128_SHA

*RSA_RC4_128_MD5

*RSA_NULL_SHA

*RSA_NULL_MD5

All four of these broken ciphers will work no matter if you’re running SSLv3 through TLS 1.2. Simply moving to only TLS 1.2 will not be enough to be deemed secure. It’s locking the front door but leaving the windows open.

See the below chart cross-referencing the ciphers available versus protocol support. If I were slick, I’d find a way to put the IBM i version in there for default values, but considering IBM i will allow a lot of the values, it really doesn’t make a difference what version of the operating system you’re on. Like I said above, if you’ve hard-coded weak ciphers and protocols, then you’re using weak ciphers and protocols no matter the IBM i version.

Ideally, you need to be in the green based on what you have listed in QSSLCSL and QSSLPCL. If there’s a specific application that absolutely requires a weak cipher in order to maintain support for some reason, my recommendation would be to ensure you change all other applications to individually only load secure ciphers at the application configuration level. I explain how to do this in the “Modernization of IBM i Security” article. This way, you minimize your exposure level to that one insecure application while ensuring all other applications are not compromised.

Figure 1: Protocol Versus Cipher Cross-Reference

This is a lot of work, but how important is it? With the advent of cloud computing, it’s super important. Cloud has given anyone with a PayPal account or a credit card the ability to put incredible horsepower at his or her fingertips, and cracking weak encryption keys now requires only minutes and hours instead of months and years. This particular RSA crack using Amazon’s EC2 cloud service took $75 worth of cloud computing and four hours. In 1999, it took a supercomputer and hundreds of other computers seven months to do the same job.

There’s not a major investment to harden our environments, but eventually you’ll have to answer the following:

“Why are you even doing that? Nobody would want our data.”

I hear this. A lot. From all sorts of people.

It’s a misconception, especially if you work for a small-to-medium business (SMB). The thing about SMBs is that they’re usually niche players that work with much larger players. They don’t have a large IT staff with security budgets. And they may certainly feel that they’re small enough that they’ll be overlooked by people with more important data like healthcare records. Starting to sound familiar?

In 2015, 74 percent of UK small businesses had a security breach (that they knew about) and 38 percent were attacked from the outside. That’s staggering. People want your data, no matter how big you are. While big companies are obvious targets, we need to stop thinking that we’ll never get hit. We also need to stop thinking that the IBM i operating system is completely secure. It’s not. It’s highly securable, and the degree has a lot to do with who’s doing the security and the effort they’re putting forth.

As time goes on and computing power gets stronger, we need to ensure we’re locking both the windows and the doors. If not, it’s our data that may be in jeopardy. Don’t say I didn’t warn you.