Modernization isn’t just about the user interface, language, and database. You need a security modernization strategy.

Last week, I did a webcast for COMMON entitled “IBM i and our False Sense of Security” in which I talked about a number of potential vulnerabilities for IBM i partitions. Two areas that I’ve received a lot of feedback on are encryption protocols and ciphers.

Encryption Protocols

You need to be aware of two protocols: Secure Sockets Layer (SSL) and Transport Layer Security (TLS). SSL is the predecessor to TLS. When one speaks about encryption protocol, either of those two protocols may often be referred to as simply “SSL.” This is where we have to be careful. For the purposes of this article, SSL means Secure Sockets Layer. While SSL is a widely used protocol, SSLv2 was deprecated in 2011 and SSLv3 in 2015. As well, SSL was never an Internet standard unlike TLS. Furthermore, the security strength differences are much higher going from TLS 1.0 to 1.1/1/2 compared to SSLv3 to TLS 1.0. That first version of TLS is deemed relatively untrustworthy in comparison because of the dangerous potential fallback allowances to SSLv3, otherwise known as the POODLE vulnerability.

Make no mistake, if you are using a broken encryption protocol, then your system is at risk.

You control the encryption protocols on IBM i using system value QSSLPCL (Secure Sockets Layer Protocols). You can manually specify the protocols, or you can use the default IBM i version supported protocols if you use the shipped value of *OPSYS.

These are the default values for QSSLPCL *OPSYS:

• 6.1—*SSLV3, *TLS1.0
• 7.1—*SSLV3, *TLS1.0
• 7.2—*TLS1.0, *TLS1.1, *TLS1.2

When you upgrade to IBM i 7.2, the default *OPSYS value for QSSLPCL means that you’re no longer using SSLv3. It’s TLS 1.0, 1.1 and 1.2. This doesn’t mean you’re not using SSLv3 or even SSLv2! For instance, 7.2 does support SSLv2 and SSLv3. If you’ve manually set your QSSLPCL system value to use SSLv2 and SSLv3, and you upgrade to 7.2, then your applications can use SSLv2 and SSLv3.

Would someone have ever manually edited your QSSLPCL? Of course. For instance, if you’re on 7.1 Technology Refresh 6 or higher, you have the ability to use TLS 1.1 and 1.2, but you must manually edit them into the QSSLPCL system value in order for any applications on your system to use them. Eventually, TLS 1.1 will be deprecated, and because you’ve manually specified its usage, you’ll eventually have to remove it too.

If you’re looking at manually disabling SSLv2 and SSLv3, you can do it at the application level. This is probably the safest route you can take. If you alter the QSSLPCL system value, you’re applying those protocol rules to all applications. There’s more risk in breaking an old application that actually requires SSLv3. If you change it at the application level, then you can accomplish two things. First, you understand what protocols an application supports. Second, you can minimize risk to disturbing other applications as you test.

Here’s an example of a component of one of my httpd.conf files for IBM HTTP Server. As you can see, the last line specifies the encryption protocols I want this server to use; in this case only TLS 1.2.

LoadModule ibm_ssl_module /QSYS.LIB/QHTTPSVR.LIB/QZSRVSSL.SRVPGM

SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA                    

SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA                    

SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA                    

SSLVersion TLSV1.2

Ciphers!

What’s a cipher?

Ancient Greeks used one of the earliest forms of cryptography in a military tool called the scytale. It was a leather belt with characters written on the back side. When viewed in linear fashion, it was meaningless but when it was wrapped around a piece of wood with the correct diameter, the encoded message could then be read.

In modern computing terms, ciphers are simply algorithms for encrypting and decrypting data. If you’re using weak or broken ciphers, then your risk for having your system or data compromised increases. IBM i supports many ciphers. Just as IBM has taken steps to make the QSSLPCL default values stronger with the removal of SSLv2 (at 6.1) and SSLv3 (at 7.2), they’ve also removed old ciphers from the default values of the QSSLCSL system value, which is the SSL Cipher Specification List. This list is read-only unless the QSSLCSLCTL (SSL Cipher Control) system value is set to *USRDFN.

Now, because there are a few years in between releases and the ciphers listed in QSSLCSL, there’s a window where ciphers can be deemed weak or broken. Furthermore, some new ciphers won’t take effect unless you’re using newer protocols like TLS 1.2. Cipher support is a little more volatile than protocol support.

For IBM i 7.1, the default values for QSSLCSL are:

*RSA_AES_128_CBC_SHA

*RSA_RC4_128_SHA >>>> WEAK

*RSA_RC4_128_MD5 >>>> WEAK

*RSA_AES_256_CBC_SHA

*RSA_3DES_EDE_CBC_SHA

*RSA_DES_CBC_SHA >>>> WEAK

*RSA_EXPORT_RC4_40_MD5 >>>> WEAK

*RSA_EXPORT_RC2_CBC_40_MD5 >>>> WEAK

*RSA_NULL_SHA >>>> WEAK

*RSA_NULL_MD5 >>>> WEAK

For IBM i 7.1, the allowed values for QSSLCSL are:

*RSA_AES_128_CBC_SHA

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

*RSA_RC4_128_SHA >>>> WEAK          

*RSA_RC4_128_MD5 >>>> WEAK        

*RSA_AES_256_CBC_SHA

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

*RSA_3DES_EDE_CBC_SHA    

*RSA_DES_CBC_SHA >>>> WEAK        

*RSA_EXPORT_RC4_40_MD5 >>>> WEAK  

*RSA_EXPORT_RC2_CBC_40_MD5 >>>> WEAK

*RSA_NULL_SHA >>>> WEAK            

*RSA_NULL_MD5 >>>> WEAK    

*RSA_NULL_SHA256 >>>> WEAK

*RSA_RC2_CBC_128_MD5 >>>> WEAK

*RSA_3DES_EDE_CBC_MD5

*RSA_DES_CBC_MD5 >>>> WEAK

So if you’re on IBM i 7.1 pre-Technology Refresh 6, 70 percent of your ciphers are considered weak. If you’re running TR 6 or higher, that would move the needle to 63 percent with the addition of the RSA_AES_128_CBC_SHA256 and RSA_AES_256_CBC_SHA256 ciphers. Those two ciphers also depend on the manual addition of TLS 1.2. Luckily, you do not need to manually edit QSSLCSL to include them. They are added to the default list automatically.

If you’ve set your QSSLCSLCTL system value to user-defined, you may not be taking advantage of new ciphers or you may still have some old ones that are supported on 7.1, like *RSA_DES_CBC_MD5, *RSA_RC2_CBC_128_MD5, and *RSA_NULL_SHA256.

On IBM i 7.2, the default values for QSSLCSL get a little longer:

*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 >>>> WEAK

*ECDHE_RSA_RC4_128_SHA >>>> WEAK

*RSA_RC4_128_SHA >>>> WEAK

*RSA_RC4_128_MD5 >>>> WEAK

*RSA_DES_CBC_SHA >>>> WEAK

*RSA_EXPORT_RC4_40_MD5 >>>> WEAK

*RSA_EXPORT_RC2_CBC_40_MD5 >>>> WEAK

*ECDHE_ECDSA_NULL_SHA >>>> WEAK

*ECDHE_RSA_NULL_SHA >>>> WEAK

*RSA_NULL_SHA256 >>>> WEAK

*RSA_NULL_SHA >>>> WEAK

*RSA_NULL_MD5 >>>> WEAK

The many new ciphers added in 7.2 bring down the level of weak default ciphers to 43 percent.

Be aware that in 7.2, there are three additional ciphers that are supported but are not included in the default values for QSSLCSL. Again, if you’ve set QSSLCSLCTL to *USRDFN, they may still exist inside QSSLCSL. These are *RSA_DES_CBC_MD5, *RSA_3DES_EDE_CBC_MD5, and *RSA_RC2_CBC_128_MD5. Plus, new ciphers would not be available to you unless you’ve manually added them in.

Again, you can specify what ciphers you want to use at the application level first. Check the httpd.conf file example once more. The three middle lines specify what ciphers I want to use on that particular IBM HTTP Server:

LoadModule ibm_ssl_module /QSYS.LIB/QHTTPSVR.LIB/QZSRVSSL.SRVPGM

SSLCipherSpec TLS_RSA_WITH_AES_256_CBC_SHA                    

SSLCipherSpec TLS_RSA_WITH_AES_128_CBC_SHA                    

SSLCipherSpec SSL_RSA_WITH_3DES_EDE_CBC_SHA                    

SSLVersion TLSV1.2

The good thing about ciphers is that legit connection attempts will try to use the highest cipher possible. The bad thing is that illegitimate connection attempts (ones from the bad guys) will try to use the weakest cipher. If your server supports weak ciphers, then that’s an additional risk to your business.

This is just another part of modernization. When we think about modernization, usually the first things that come to mind are the user interface, database, or language. Security needs to be a part of any modernization strategy. In fact, it needs to be a strategy on its own. It’s not just user profiles with bad passwords and special authorities. Those are serious concerns, but those are entirely inside the box (pun intended). We must be looking at the big picture and see IBM i from the outside. We need to be thinking how would someone with no knowledge of IBM i would attempt to compromise it. Those are universal exploits, and just as big of a concern.