How PeopleSoft uses SSL when acting as the Client

Previously, I wrote about SSL and how Weblogic utilizes it from a server perspective.  This article provides a followup analysis from a client perspective, the client being the PeopleSoft system.  We will look at a few examples of different client uses in PeopleSoft and how we can control the protocol used.

Analysis of the Defaults

This is a look from a PeopleTools 8.53/8.54 perspective which use Java 7.  It applies to older versions using Java 6 from the default connectivity perspective.  However, since Java 6 is incapable of using anything newer than TLSv1.0 the options provided to control the protocol do not apply.  Those implementations are stuck at TLSv1.0.

Let’s identify some examples of where PeopleSoft may be acting as a client.

1. Outbound Integrations from the Integration Gateway
2. App Server to Integration Gateway
3. Report Posting
4. Portal/Interaction Hub Content
5. Built-In Attachment PeopleCode functions

From what I’ve come across, almost all HTTPS requesting traffic from PeopleSoft is Java generated.  One exception may be connectivity that uses the libpscurl library which provides PSCurlFileTransferSession functionality.  The Built-In Attachment functions use this library.  We know the Integration Gateway is Java based (it runs in Weblogic after all) and report posting also uses Java Native Interface (JNI) to use Java code from the Tuxedo processes.  In addition, the loading of Gateway Connectors and outbound communication from the App Server to the Integration Gateway also are Java based.

Since we are primarily dealing with Java, let’s refer to the default SSL protocols to see what behavior we should expect.

* TLS 1.1 and 1.2 protocols exist but will not be used unless client code or configuration requests them.
** As of Java 8u31, 7u75, and 6u91; SSL3 is disabled and requires explicitly enabling it. See the release notes for these versions for more details

Based on this info, we should be able to communicate with an external integration point that has disabled SSLv3 without any modifications of our own.  We can do a simple ping test with an external node to validate this.  With SSL Handshake debugging enabled we can see in the Weblogic logs that from a client standpoint the connection is initiated with TLSv1 aka TLSv1.0.

Is initial handshake: true
Is secure renegotiation: false
<Notice> <Stdout> <BEA-000000> <%% No cached client session>
<Notice> <Stdout> <BEA-000000> <*** ClientHello, TLSv1>

Lets look at the same thing when the Distribution Agent process posts to an HTTPS server:

Is initial handshake: true
Is secure renegotiation: false
Thread-0, setSoTimeout(300000) called
%% No cached client session
*** ClientHello, TLSv1

The same can be seen when loading connectors or making a request to ping a node (app to IG call).  With this information we can see Java is holding true to it’s defaults and there does not appear to be any downside impact from eliminating SSLv3 from Weblogic.

What would happen if TLSv1 was disabled as well and only TLSv1.1 and higher were allowed.  When we test such a scenario we see the client call still uses TLSv1 so the handshake fails. No surprise there right?  Here are some of the errors produced:

javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported>

<Notice> <Stdout> <BEA-000000> <[ACTIVE] ExecuteThread: '0' for queue:
 'weblogic.kernel.Default (self-tuning)', handling exception: javax.net.ssl.SSLHandshakeException:
  Received fatal alert: handshake_failure>

Integration Gateway - External System Contact Error (158,10721)

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
        at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
        at psft.pt8.pshttp.https.HttpsClient.doConnect(HttpsClient.java:246)
        at sun.net.NetworkClient.openServer(NetworkClient.java:136)
        at psft.pt8.pshttp.https.HttpClient.openServer(HttpClient.java:529)
        at psft.pt8.pshttp.https.HttpClient.<init>(HttpClient.java:350)
        at psft.pt8.pshttp.https.HttpsClient.<init>(HttpsClient.java:76)
        at psft.pt8.pshttp.https.HttpsClient.newClient(HttpsClient.java:132)
        at psft.pt8.pshttp.https.HttpsClient.newClient(HttpsClient.java:100)
        at psft.pt8.pshttp.https.HttpsURLConnection.connect(HttpsURLConnection.java:465)

I did not dig into using the built-in file attachment functions too much.  They use what looks to be a customized libcurl library.  I can see that libpscurl uses libpsssl which also appears to be a customized OpenSSL library.  The version of OpenSSL is 0.9.8m which is end of life at the end of 2015.  This version of OpenSSL, like Java 6, does not support TLSv1.1 or TLSv1.2 so there is not much we can do here.

Controlling the Protocol

There are a couple ways to control the client protocol. One option for external nodes is to add the SSLProtocols header property to the Node and Service Operations.  The valid values for this property are: TLSv1, TLSv1.1, TLSv1.2.

Performing one of the tests again we now see in the log we are in fact using TLSv1.2

 <*** ClientHello, TLSv1.2>

This option can’t be used for settings at the App or Process Scheduler though.  Therefore, we must use the java system property https.protocols.  The JSSE Reference Guide for Java says the following about this property.

https.protocols system property. This contains a comma-separated list of protocol suite names specifying which protocol suites to enable on this HttpsURLConnection. See the SSLSocket setEnabledProtocols(String[]) method.

The values for https.protocols are also TLSv1, TLSv1.1, TLSv1.2.  We can also use this to control all client https protocols from Weblogic if we wanted, rather than using the Node/Routing settings.  If used for Weblogic, I recommend adding this in the same spot as the SSLv3 disable option, the setEnv.sh JAVA_OPTIONS variable.  For an App or Process Scheduler this should be added to the JavaVM Options line in the respective config file.

-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2

A Warning

Java will try to use the highest protocol available in the list first.  This holds true for the SSLProtocols header option as well.  Which also can take multiple values that are comma separated.  I’ve done some limited testing with multiple options set via https.protocols.  Your mileage may vary when using this setting, especially at Weblogic.  Certain older offending SSL implementations will not properly respond when negotiating TLS, they essentially hang up rather than reply back with a protocol to use.  As an example this happens if you were using the Certicom engine with Weblogic and you had your App Server set to use -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2.  But if you connect to Apache with the same setting while Apache has TLSv1.2 disabled the connection successfully negotiates to TLSv1.1.

Summary

Hopefully you found this series on SSL and PeopleSoft’s use of it informative.  I would summarize that as of 2015 (PeopleTools 8.53/8.54) we can safely disable SSLv3 at the web server in most cases.  No real change is required to support this change from the App or Process Scheduler that I’ve found, as the communication should be using TLSv1 already.  From the outbound external integration standpoint, I recommend using Node and Routing settings rather than https.protocols if you need to deal with any older systems still.  This gives you fine grain control by Routing.  I expect older PeopleSoft implementations that have not been updated may start to struggle if they have external integrations.  I’ve seen reference to some companies disabling TLSv1.0.  But just today, I saw a post on the OTN forums asking for help on a PeopleTools 8.48 system which would be using Java 1.4 and not even have TLSv1.0 capabilities.

Keep in mind that Oracle has disabled SSLv3 in Java now, if you keep your JDK’s up to date you shouldn’t have to do anything additional to disable the SSLv3 as the JDK should take care of it for you.

Starting with the January 20, 2015 Critical Patch Update releases (JDK 8u31, JDK 7u75, JDK 6u91 and above) the Java Runtime Environment has SSLv3 disabled by default.

References:

• Java SE SSL v3.0 Instructions
• JSSE Reference Guide for Java
• Integration Broker Inbound and Outbound Request Flows