Upgrading to TLSv1.2

Body

Thanks to Alyson Comer, the IBM z/OS System SSL architect, for co-authoring this entry, and to Mike Kasper of the IBM z/OS System Integrity Team for his encouragement and contributions to this effort. 

In recent years, there has been much emphasis on eliminating the use of older SSL and TLS protocol versions and moving up to TLSv1.2. When upgrading System SSL applications or AT-TLS rules from older TLS/SSL protocol versions to TLSv1.2, there are several configuration attributes that must be reviewed and possibly updated to ensure successful connectivity. In addition, upgrading provides an opportunity to adopt stronger cryptographic protection and align your TLS configuration with best practices. Let’s take a look at the required changes as well as some best practices to consider.

Required Actions

• Some cipher suites supported under earlier TLS and SSL versions are not supported under TLSv1.2. If any of your TLS/SSL connections currently use any of the following cipher suites, you must work with your communication peer to agree on, and configure at both ends, an acceptable cipher suite that is supported by TLSv1.2:
  • x'0003' - TLS_RSA_EXPORT_WITH_RC4_40_MD5
  • x'0006' - TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
  • x'0009' - TLS_RSA_WITH_DES_CBC_SHA
  • x'000C' - TLS_DH_DSS_WITH_DES_CBC_SHA
  • x'000F' - TLS_DH_RSA_WITH_DES_CBC_SHA
  • x'0012' - TLS_DHE_DSS_WITH_DES_CBC_SHA
  • x'0015' - TLS_DHE_RSA_WITH_DES_CBC_SHA

Note that the System SSL default cipher list does not use any of the unsupported cipher suites.  Since all the cipher suites in the default cipher list are supported by TLSv1.2, no cipher suite changes are required for applications or rules that use the default list.

• TLSv1.2 does not allow the use of MD2 in digital signatures. If any of your or your communications partners' certificates (or any of the certificates in the associated certificate chains) use MD2 in their digital signatures, those certificates will be rejected during a TLSv1.2 handshake. The owner of any such certificates must obtain and install new certificates with stronger digital signatures before a TLSv1.2 handshake will succeed.

Best Practices

Cipher Suites

TLSv1.2 supports several newer and stronger cipher suites than its predecessors. These include ephemeral Elliptic Curve key exchange, AES-GCM mode encryption and SHA-256 and SHA-384-based message integrity algorithms.

• x'C02B' - TLS_ECDHE_ECDSA_WITH_AES_128_ GCM_SHA256
• x'C02C' - TLS_ECDHE_ECDSA_WITH_AES_256_ GCM_SHA384
• x'C02F' - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• x'C030' - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Assuming the appropriate support by the communication peer, best practices suggest:

• Use strong cipher suites.
  • Prefer those that use AES encryption (GCM preferred over CBC). If possible, avoid those that use 3DES, DES and RC4. 
  • Those that use NULL encryption should only be selected in cases where you intentionally want to provide message integrity protection without encrypting the traffic.   These cases tend to be very rare and should be reviewed very carefully.
  • Prefer those that use SHA-256 or stronger message integrity. If possible, avoid those that use SHA (SHA-1) and MD5.
  • While suites that use ephemeral Diffie-Hellman key exchange (DHE and ECDHE) are more secure than their fixed counterparts (DH and ECDH), they also require significantly more CPU cycles. If your application generates large numbers of TLS handshakes, be aware that the use of DHE and ECDHE cipher suites can cause unusually high CPU consumption.
  • Do not use x'0000' - TLS_NULL_WITH_NULL_NULL
• Specify your own list of cipher suites (instead of using the default list) in order from strongest to weakest.
• Refer to the z/OS System SSL Programming Guide and Reference Appendix C for a complete list of supported cipher suites.

Digital certificates

Best practices suggest:

• Using certificates with RSA key sizes of at least 2048-bits or ECDSA key sizes of at least 256 bits.
• Using certificates signed with a digital signature based on the SHA-2 (SHA-224, SHA-256, SHA-384 or SHA-512) hashing algorithm.

In addition, there are some important considerations regarding the configuration of Signature Algorithm Pairs. TLSv1.2 allows the specification of digital signature algorithm pairs that are acceptable within the peer digital certificate. Each pair includes an asymmetric algorithm (RSA, ECDSA, etc.) and a hashing algorithm (SHA, SHA-256, SHA-384, etc.). Prior to TLSv1.2, there was no way to limit the allowable algorithms, so certificates using any pair of algorithms -- even very weak ones -- would be accepted. When upgrading to TLSv1.2, the System SSL and AT-TLS default is to accept any signature pair, which will ensure a smooth upgrade in this respect.

Best practices suggest that Signature Algorithm Pairs that use MD5 or SHA (SHA-1) should be avoided. However, placing any limits on the allowed pairs (including the exclusion of MD5 and SHA), opens the possibility of failing a handshake that previously succeeded with an earlier TLS or SSL version. Specifically, if your communication partner uses a digital certificate that uses any of the excluded algorithms, then that certificate will be rejected during the TLSv1.2 handshake. For this reason, it is important that any such changes be coordinated with the owners of any potential peer certificates.

Client ECurves

The use of Elliptic Curve Cryptography (ECC) was introduced to TLSv1.0 and TLSv1.1 with RFC4492 and is built into TLSv1.2. When using ECC-based key exchange, the TLS client may indicate the specific set of elliptic curves that it is willing to use with its communication partner. System SSL and AT-TLS call this the "client ecurve list" or simply "client ECurves." Since System SSL supports client ECurve specifications on all TLS protocols, no upgrade action is required when moving up to TLSv1.2.  Any specified ECurve list will continue to work under TLSv1.2 as it did with previous protocol versions.

FIPS 140 mode

• If you have FIPS 140 mode enabled, then you are already limited to cipher suites that are acceptable to TLSv1.2. Regardless, it is always a good idea to review your cipher suites and make sure that you are adhering to best practices as described above.
• If you do not have FIPS 140 enabled, then any of the considerations listed above may apply to you, including the unacceptable cipher suites. Please make any required adjustments as described above.

Hopefully, this information will help you with your upgrade to TLSv1.2 if you haven't already upgraded. But what about TLSv1.3, now that it's an adopted standard? Glad you asked! 

In z/OS V2R4, System SSL and AT-TLS will provide basic TLSv1.3 support. Look for another blog entry here in the coming months that will point out some highlights and a few guidelines for upgrading to this brand new protocol version.