I'm sure we've all heard of the HeartBleed security issues on systems based on the OpenSSL platform. Because of this, people assume the IBM i is affected and are being required to update their SSL/TLS processing defaults to use newer versions of TLS (mainly v1.1 or higher) for PCI compliance.
Recently we had a customer on V7R1 run into issues with GETURI and the SSL versions they were using because of PCI compliance. They need to use TLS v1.1 or TLS v1.2. This means changing the system value for QSSLPCL to *TLSV1.1 *TLSV1.2.
Because MAILTOOL also uses the same system SSL APIs this will apply to that as well.
The problem occurred when running GETURI and they were receiving a return code error of -13 (SSL_ERROR_UNSUPPORTED). If they added *TLSV1.0 back into the system value for QSSLPCL things worked fine. But, that means they were not PCI compliant.
Right away I got a virtual loaner system on V7R2 to test. Things worked fine there as well. So, it seems like on V7R1 there are some issues with SSL and they're not quite caught up with PTFs available.
The customer worked with IBM and after many days they offered a workaround to change the SSL version used on the SSL Handshake operation. The default has always been zero (which should work, and IBM even admitted to this). They said to try versions of 4, 7 or 8 (version values can be seen here). Part of the conversation is as follows:
| It appears to me that the applications is calling SSL_Handshake(), and in the SSLHandleStr is using Protocol 0: SSL_Version_Current.
On R720 GA, that is [TLSv1.2, TLSv1.1, TLSv1].
On R710 GA, that is [TLSv1, SSLv3].
When SSLv3 and TLSv1 are both disabled via QSSLPCL, there are no matching protocols available, which results in the 'not supported' return code.
When TLSv1.2 and TLSv1.1 were added in TR6, I would have expected SSL_VERSION_CURRENT to adapt, but perhaps it is still working with the default shipped values, or perhaps it is using the versions that were available when the application was compiled.
This is the table from InfoCenter, the API definition:
SSL_VERSION_CURRENT 0 (Uses the default protocols as determined by the intersection of Security system value QSSLPCL and the eligible default protocols from the SSLCONFIG macro) SSL_VERSION_2 2 (SSL Version 2.0 only) SSL_VERSION_3 3 (SSL Version 3.0 only) TLS_VERSION_1 4 (TLS Version 1.0 only) TLSV1_SSLV3 5 (TLS Version 1.0 with SSL Version 3.0 compatibility) TLS_VERSION_1_0 6 (TLS Version 1.0 only) TLS_VERSION_1_1 7 (TLS Version 1.1 only) TLS_VERSION_1_2 8 (TLS Version 1.2 only) TLSV12_TLSV11_TLSV10 9 (TLS Version 1.x only) TLSV12_TLSV11_TLSV10_SSLV3 10 (TLS Version 1.x with SSL Version 3.0 compatibility)
This to me sounds like on V7R1 when TLS v1.2 and TLSv1.1 were added the current values for the SSL_Version_Current should have been updated, but wasn't. I don't see how the values when compiled would make a difference as these are system values.
So, for the latest version of GETURI (v4.10 SP150609) as well as MAILTOOL (v8.10 and up) we have created data areas in the applications that will hold the SSL protocol version to use when calling either GETURI or MAILTOOL.
The customer has reported that they chose to use option 9 (which is TLS v1.x only) and it worked fine and solved the problem.
Feel free to contact us for any questions regarding this issue.