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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online