IBM i 7.4 Tip #2: Secure sockets layer (SSL) and Transport Layer Security (TLS) changes

Pete Massiello, iTech
Pete Massiello

At each release, IBM tightens up the security of the system, which is a good thing for many shops.  There are two system values, which while you might have set to *OPSYS, the underlying security will change when you upgrade to a new release.  Now, I certainly recommend that most places have both System Values QSSLPCL (Secure Sockets Layer Protocols) and QSSLCSLCTL (Secure Sockets layer cipher control) both set to *OPSYS.  This way, when IBM changes the defaults associated with the release, you get the newer versions, but you should be aware of the changes that will happen when upgrading to IBM i 7.4.  All for the better in my opinion. So, let’s discuss Secure sockets layer (SSL) and Transport Layer Security (TLS) changes.

TLS enabled and default cipher specification lists have changed for System TLS

The System TLS enabled cipher specification list no longer contains Triple Des (3DES), Cipher Block Chaining (CBC), or RSA key exchange ciphers when the QSSLCSLCTL system value is *OPSYS. If one of those ciphers is needed, the administrator must add it to system value QSSLCSL. Administrators control the ciphers enabled for System TLS using the system values QSSLCSL and QSSLCSLCTL.

The System TLS shipped eligible default cipher specification list no longer contains Triple Des (3DES), Cipher Block Chaining (CBC), or RSA key exchange ciphers. If one of these ciphers must be added to the default protocol list after it has been added to the enabled list, use the System Service tools Advanced Analysis command TLSCONFIG option “eligibleDefaultCipherSuites” to add the value.

The System TLS default cipher specification list is now:

  • AES_128_GCM_SHA256
  • AES_256_GCM_SHA384
  • CHACHA20_POLY1305_SHA256
  • ECDHE_ECDSA_AES_128_GCM_SHA256
  • ECDHE_ECDSA_AES_256_GCM_SHA384
  • ECDHE_RSA_AES_128_GCM_SHA256
  • ECDHE_RSA_AES_256_GCM_SHA384

System TLS support for SSLv2 has been removed

The Secure Sockets Layer version 2.0 protocol (SSLv2) can’t be turned on for System TLS. *SSLv2 can’t be added to the QSSLPCL system value. If present, *SSLv2 will be removed from CHGSYSVAL list for the QSSLPCL system value. If you are using SSLv2, you will need to move to TLSv1.2 before upgrading to 7.4.

TLSv1.3 protocol has been enabled for System TLS

The Transport Layer Security version 1.3 protocol (TLSv1.3) is now enabled and used by default for System TLS. TLSv1.3 can be disabled by changing the QSSLPCL system value. If TLSv1.3 must be removed from the default protocol list, use System Service tools Advanced Analysis command TLSCONFIG option “eligibleDefaultProtocols” to remove the value.

 TLSv1.1 and TLSv1.0 protocols have been disabled for System TLS

The Transport Layer Security version 1.1 protocol (TLSv1.1) and Transport Layer Security version 1.0 protocol (TLSv1.0) are now disabled by default for System TLS. TLSv1.1 or TLSv1.0 can be re-enabled by changing the QSSLPCL system value. If TLSv1.1 or TLSv1.0 must be added to the default protocol list, use System Service tools Advanced Analysis command TLSCONFIG option “eligibleDefaultProtocols” to add the value.

TLS default signature algorithm certificate list has changed for System TLS

The System TLS default signature algorithm certificate list no longer contains ECDSA_SHA224, ECDSA_SHA1, RSA_SHA224, RSA_SHA1, or RSA_MD5 signature algorithms. The enabled signature algorithm certificate list still contains those values. For applications using the default list, certificates with those signatures will not be allowed. Applications can explicitly set the list if the default list is too restrictive. The most limited way to accomplish this is to use Digital Certificate Manager to change the explicit list for only the specific Application Definition requiring these algorithms.  If one of these algorithms must be added to the default signature algorithm certificate list, use System Service tools Advanced Analysis command TLSCONFIG option “defaultSignatureAlgorithmCertificateList” to add the value.

If you wish to check on what protocols you are doing, Steve Pitcher did an excellent article in our March 2017 Newsletter. https://www.itechsol.com/march-2017-newsletter/ You will want to check what you are using before upgrading to any release.

Tagged with: , , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *

*