Re: Identifing which SSL method used when IBM i is the client - disabling TLSv1.0 in favor of TLSv1.1 or TLSv1.2 -- MIDRANGE-L

Paul,

Any application using the IBM SSL APIs is easily changed to not use
"Current Version" by changing a parameter value on the Handshake API.

I'm sure this is the case with the GSK APIs as well.

But, if the issues you can't update the client software to not use
0/Current then I see your issue and really only an IBM PTF will fix that.
I've dealt with them on this and they sort of tic admitted "woops". :)

If the issue is with our GETURI software or a 3rd party app that uses it, I
can help get it fixed. Same with MAILTOOL. We have updated our
applications to get around this. I'm pretty sure we've already discussed
this but here's a link for our specific issue:
http://www.fieldexit.com/forum/display?threadid=170

Brad
www.bvstools.com

On Mon, Jun 29, 2015 at 1:53 PM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>
wrote:

This is a multiple purpose thread.

1) Is there a way to determine which one of the five methods are used in
an SSL connection when IBM i is the client.
After changing the 3 SSL system values, it was discovered that these
changes do not directly change an SSL client app.
I'm still researching, but I finding that we are using all of the five
methods below.

http://www.ibm.com/developerworks/ibmi/library/i-system-ssl-ibmi/

Currently, MANUAL CHANGES ARE REQUIRED TO EACH APP TO ENABLE TLSv1.2
If IBM would make a change, client apps may not need to be touched.

In several cases, the client app was created using IBM I defaults, thus
changing the client app is not a simple change.

One of our client apps uses the IBM I SSL_APIs, which, by default, only
supports SSL_VERSION_CURRENT 0 (TLS Version 1.0 with SSL Version
3.0 and SSL Version 2.0 compatibility)
Per IBM development (Open PMR), changing the app to use
TLSV12_TLSV11_TLSV10 9 (TLS Version 1.x only) would only work for
V7R1, this will break at V7R2.
A previous related thread suggested changing this to 9, not recommended at
this point.

SSLHandle
SSL_VERSION_CURRENT 0 (TLS Version 1.0 with SSL Version 3.0 and
SSL Version 2.0 compatibility)
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)

The client app could be using any of the below.
Secure sockets consists of the following APIs:

IBM(r) i Global Secure Toolkit (GSKit) APIs

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/unix9a.htm?lang=en-us&cp=ssw_ibm_i_71

IBM i SSL_ APIs

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/unix9b.htm?lang=en-us&cp=ssw_ibm_i_71

Open SSL APIs

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/openssl.htm?lang=en-us&cp=ssw_ibm_i_71

IBM PASE for i shells and utilities

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzalf/rzalfpasecommands.htm?lang=en

Secure Sockets Layer and Java Secure Socket Extension
http://www.oracle.com/technetwork/java/index.html

2) A DCR was suggested. Before I submit one, I would like some feedback
from the group, and possibly others requesting a similar change.
One option is to have SSL_VERSION_CURRENT also include TLSv1.1 and
TLSv1.2. This would allow any client app to work without any changes,
without breaking any clients still using V3.0 or V2.0.
Another option, if possible, was to have both the GSkit and SSL API, that
if the SSL protocol was null, it would then look and use system default
value QSSLPCL

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx
http://www.pencor.com/

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.