IBM i 7.2 System SSL Enhancements
IBM i 7.2 System SSL underwent the most significant updates since Transport Layer Security (TLS) version 1.0 was originally introduced in V4R5 more than a decade ago. Overwhelming accurately describes any attempt to list or quantify all of the enhancements. From a high level, support for TLSv1.2 and Elliptic Curve Cryptography (ECC) are the big-ticket items. A closer look reveals additional enhancements to System SSL in conjunction with those items.
What is System SSL?
System SSL is a set of services provided in the IBM i Licensed Internal Code to protect TCP/IP communications using the SSL/TLS protocol. System SSL is accessible to application developers from the following programming interfaces and Java Secure Socket Extension (JSSE) implementation:
- Global Security Kit (GSKit) APIs
- Integrated IBM i SSL_ APIs (Not recommended. Use GSKit instead.)
- Integrated IBM i JSSE implementation
SSL applications created by clients or by IBM that leverage an interface listed above use System SSL. FTP and Telnet are examples of IBM applications that use System SSL. Not all SSL-enabled applications running on IBM i use System SSL.
IBM i 7.1 TR6
The 7.2 story actually begins with the IBM i 7.1 TR6 release in 2013. It was at that time that some of the 7.2 capabilities were released early. The TLSv1.2 protocol was the primary capability provided at that time. The limitations of a Technology Refresh resulted in differences with how the new capabilities are accessed between 7.1 and 7.2. For those unfamiliar with the previous 7.1 TR6 System SSL enhancements, two articles were written at that time describing them.
The iCan blog article “New System SSL Support” delves into the details of TLSv1.2. That information is relevant for 7.2 so it’s worth the time to read it before continuing here.
The second article of interest is “How to use TLSv1.2 with System SSL on IBM i 7.1” located on developerWorks. The article includes a detailed description of the requirements and configuration steps needed to use TLSv1.2 with the Technology Refresh.
SSL/TLS Protocol Changes
It’s routine for IBM i System SSL to change default properties on a release boundary and 7.2 changed several such properties. The change with the most impact is that the TLSv1.2 and TLSv1.1 protocols are on and SSLv3 is off by default. The QSSLPCL system value controls the TLS versions supported by system SSL with the special value *OPSYS indicating the default behavior. Changing the setting for QSSLPCL or the meaning of *OPSYS influences every System SSL consuming application on the system.
When migrating from an earlier release, a user-defined QSSLPCL value is retained preventing the new default behavior for this release from being in effect. In that case after the migration, the system administrator can set QSSLPCL to *OPSYS if its definition for the release meets the security policy requirements.
QSSLPCL *OPSYS definitions by release are:
IBM i 7.2 -- *TLSV1.2 *TLSV1.1 *TLSV1
IBM i 7.1 -- *TLSV1 *SSLV3
If *OPSYS doesn’t meet the requirements, the administrator simply updates the user configured list of protocols to meet the requirements.
Disabling SSLv3 in the default configuration reflects the security community’s position that SSLv3 should no longer be used. The reality is that some old devices or applications used in production environments are still dependent on this deprecated protocol version. If such a device must continue to use SSLv3 with the 7.2 partition, the administrator must update QSSLPCL to once again include *SSLV3. When *SSLV3 is included in QSSLPCL, SSLv3 is added to the default protocols used by a majority of applications. In this case, SSLv3 use should be restricted to the one application that needs it to limit the exposure. Unfortunately, that means all applications using the default protocols must have it individually turned off to prevent its use. For the core IBM networking applications this can be controlled using the Digital Certificate Manager (DCM) Application Definition. If SSLv3 is re-enabled, create an action plan to eliminate the external dependency on SSLv3 so it can be turned off again.
The 7.2 release enables TLSv1.2 and TLSv1.1 under the covers for applications coded to use TLSv1.0. This is due to the focus on improving the default security position without requiring client intervention. 7.1 TR6 requires the new protocols explicitly be turned on for each application. The possibility exists that an application’s internal code will not tolerate negotiation of a new protocol it doesn’t “know” about. In this situation, the mitigation is to turn off the new protocols at the application layer if possible. This is accomplished through changing the application definition in DCM or by changing the application code to explicitly turn off TLSv1.2. The last option is to disable TLSv1.2 with QSSLPCL for the entire system until the application can be updated to tolerate TLSv1.2.
Cipher Specification List Changes
The system value QSSLCSLCTL determines what controls the values in system value QSSLCSL. *OPSYS means the operating system determines the list while *USRDFN means the system administrator controls the QSSLCSL values. The new definition of the cipher suite list in QSSLCSL, when QSSLCSLCTL is set to *OPSYS, also has an impact to clients. QSSLCSL governs both the supported and default cipher suites. 7.2 *OPSYS introduces more than a dozen new cipher suites for the first time. The default cipher suites are a release-restricted subset of the supported cipher suites. Some cipher suites previously in the restricted default subset have been removed from the subset. The order of some suites in the default subset has also changed, which can impact which cipher suite is negotiated. Before identifying the specific changes to the list, we need to know the functionality associated with the new cipher suites.
Elliptic Curve Cryptography (ECC)
ECC is the primary new function available for the first time with the 7.2 release. ECC is an asymmetric encryption algorithm and, in simplistic terms, it’s similar to RSA. One of its attributes is that it has smaller key sizes than RSA to obtain the same strength. ECC encompasses many different elliptic curve types, families and strengths. System SSL and DCM support five named elliptic curves referred to as: Secp521r1, Secp384r1, Secp256r1, Secp224r1 and Secp192r1. All five of the named curves are enabled by default. System SSL support for one or more of the named curves can be disabled at the system level using the System Service Tools advanced analysis SSLCONFIG command.
As it relates to TLS, ECC has two components. The first part of ECC is Elliptic Curve Digital Signature Algorithm (ECDSA) certificates. These certificates use ECDSA for the key type rather than RSA. The second part is the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange. The ephemeral part means that a key associated with a certificate isn’t used but rather new anonymous key pairs are used for each handshake.
ECDHE doesn’t use the key in the certificate so it works with both RSA and ECDSA certificates. The keyword ECDHE in a cipher suite name indicates ECDHE is used for the key exchange. The keywords RSA or ECDSA in the cipher suite indicate which certificate type to use. If ECDHE is not in the cipher suite name, that means there’s an unwritten RSA keyword to indicate RSA key exchange. RSA key exchange uses the key from the RSA certificate thus it doesn’t work with ECDSA certificates. ECDSA certificates can only be used with ECDHE key exchange.
The transition to ECDHE for the key exchange in TLS connections is painless. It requires that each side support the same ECDHE cipher suite and has one supported named curve in common. The server’s ordered cipher suite list also must prefer the ECDHE cipher suite to any RSA key exchange cipher suites for it to be selected.
The transition to ECDSA is more complicated since, in addition to the ECDHE requirements, ECDSA requires a new certificate be generated and assigned to the application. A server application cannot migrate from RSA certificates to ECDSA certificates until all of its potential clients are able to negotiate ECDSA and ECDHE cipher suites. This is a long-term consideration when negotiating with previous IBM i releases that don’t support ECC.
Multiple Server Certificates
To assist with the interoperability issues of transitioning to ECDSA certificates, 7.2 server applications can now have multiple server certificates assigned at one time. The new multiple certificates infrastructure supports up to four concurrent certificates though two will be typical. An administrator rolling out the use of ECDSA would assign both a RSA certificate and an ECDSA certificate to the server configuration.
Servers with a DCM application definition use the DCM Update Certificate Assignment panel to assign multiple certificate labels. GSKit based servers can configure multiple certificate labels to be used by setting the attribute GSK_KEYRING_LABEL_EX.
The Telnet server’s DCM Update Certificate Assignment panel is shown in Figure 1. Telnet currently has one certificate assigned though the four certificates with the check mark next to the label names are about to be assigned instead. Assigning two or more certificates that have the exact same cryptographic properties adds unnecessary processing as only the first one as determined internally will ever be selected.
The certificate selected for a secure connection is determined by the server configuration paired with each client’s advertised capabilities. The certificate selection logic is deterministic and is described in detail in Knowledge Center article “Multiple Certificate Selection.”
Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.
comments powered by