SSL and Weblogic

As previously mentioned, I was doing an analysis of how PeopleSoft and Weblogic utilize SSL which was spawned by the announcement of POODLE.  I’m going to review my findings for Weblogic 10.3.6.x and then duplicate the analysis to see if anything is changed with Weblogic 12.1.2.  Weblogic 10.3.6.x is supported for any PeopleTools 8.50 – 8.53 installations.  If you are on an older release of Weblogic 10.3 you should upgrade your Weblogic.

Weblogic 10.3.6

First, let’s look at what Weblogic 10.3.6 provides out of the box.  10.3.6 is shipped using the Certicom SSL engine by default.  Lets see what we get with an external scan from Qualys.

As we can see by default it supports TLS 1.0, SSL3 and even says SSL2.  A look at the Protocol Details shows POODLE as mitigated already.  You may find that strange, so lets consider it further.  We see SSL 3: 0x4 at the end of POODLE SSLv3 line.  That tells us that for SSL3 the cipher 0x4 was used by the server.  So let’s look at the cipher suites.

Cipher 0x4 is TLS_RSA_WITH_RC4_128_MD5 and is known to be weak.  POODLE attacks CBC ciphers, so even though the server has CBC ciphers listed, the server is choosing the order based on what the client said it can handle and is forcing the test from Qualys to use the RC4 cipher.  Qualys considers this the lesser of two evils and currently considers SSL3 with RC4 as being mitigated. This however does not change the fact that it is insecure, and it’s stated in big red letters in the protocols section.  RC4 can be compromised, it just takes a lot more attempts.

So back to Weblogic 10.3.6 default,  the Certicom SSL engine is deprecated and official JSSE support was added in 10.3.3 I believe.  In 10.3.6 however, they still had not made JSSE the default even though that is clearly the direction people are supposed to go.  JSSE is the Java SSL implementation (Java Secure Socket Extension).  Since Certicom doesn’t support TLS 1.1 or 1.2 the only way to gain access to the newest protocols is to use JSSE with Java 7.

So here’s a few things to note already:

1. Everyone on PeopleTools 8.50 to 8.53 should be running Weblogic 10.3.6 since it is the highest supported version for all of them.
2. Weblogic 10.3.6 out of the box is considered mitigated by Qualys (at the moment that is; their webpage notes they may change the SSL3/RC4 status in the future).  But this does not mean it is secure.
3. To gain access to the newest protocols we must enable JSSE which will change our scan results.
4. JSSE with Java 6 does not support TLS 1.1 or TLS 1.2 either, same as Certicom.

Weblogic 12.1.2

Now lets look at Weblogic 12.1.2 out of the box, which is currently the only version supported by PeopleTools 8.54.  Weblogic 12.1.2 does away with Certicom all together and now is JSSE from the start. So on to the scan.

Now we see TLS1.2 – TLS1.0 and SSL3 are active.

Looking at the Protocol Details we see POODLE is now considered vulnerable.  We also see the BEAST attack also went from mitigated server side to not mitigated.  If we look at our Ciphers we now see none of the old  “INSECURE” ciphers, however the title to the section now indicates that the server has no preference in the order of the cipher.

With the Certicom SSL engine the server could use it’s preference of cipher and it would use TLS_RSA_WITH_RC4_128_MD5.  Now with JSSE server side cipher preference is lost.  I’m not going to get into the details of server preference other than, Certicom appears to have had it, JSSE from Java 6/7 does not, but an option for Java 8 has been introduced (useCipherSuitesOrder).  Unfortunately, PeopleSoft is not supporting Java 8 yet.

But wait, there’s more,

Weblogic 10.3.6 with JSSE

Perhaps you are running 10.3.6 and have already enabled JSSE because your certificate wouldn’t load with Certicom.  Well, lets take a quick look at Weblogic 10.3.6 with JSSE.  But first, lets get one thing out in the open, there are two possible results for Weblogic 10.3.6 with JSSE.  Since we are relying on Java for our SSL implementation, our results are dependent on our version of Java!  This next test is with PeopleTools 8.53 which is utilizing Java 7.  PeopleTools 8.50 – 8.52 would be using Java 6 which does not have support for TLS 1.1 or TLS 1.2.  Add that to your list of reasons for a PeopleTools upgrade!

From our scan we see the same Protocols supported as in Weblogic 12.1.2 which is also using Java 7.

We also have the same ciphers and that makes sense, since it’s using the same JSSE implementation as Weblogic 12.1.2.  The only difference that shows up is that with Weblogic 12.1.2 Secure Client-Initiated Renegotiation is enabled and we are warned that it can be used for DoS attacks.  Weblogic 10.3.6 does not have this enabled.

Disabling SSLv3

Since we are managing an ERP system and have more control over our user base than just some website on the internet, my choice is to remove SSL3 from Weblogic all together.

So you want to disable SSLv3, how can you do that?  Just add the following option to the JAVA_OPTIONS line in setEnv for your platform.

-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.0

This option works for both Certicom and JSSE SSL implementations on Weblogic 10.3.6+  If you are on an older version of Weblogic and this option doesn’t seem to work you could also try

-Dweblogic.security.SSL.protocolVersion=TLS1

This leaves us with only TLS 1.0 when used with Certicom, and we now get a scan that looks like this.

Which Qualys still gives us a big fat F.  Why? That’s because of the anonymous ciphers allowed.  One way we can tell Weblogic which cipher suites to use is by modifying the config.xml file.  For example, by adding the <ciphersuite> lines to  the <server> <ssl> section after the <enabled> tag we can limit the ciphers used to only those we specify.

<server>
   <name>PIA</name>
   <ssl>
     <name>PIA</name>
     <enabled>true</enabled>
      <ciphersuite>TLS_RSA_WITH_AES_128_CBC_SHA</ciphersuite>
      <ciphersuite>TLS_RSA_WITH_AES_256_CBC_SHA</ciphersuite>
      <ciphersuite>TLS_RSA_WITH_3DES_EDE_CBC_SHA</ciphersuite>
      <ciphersuite>TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA</ciphersuite>

This scan did not include the RC4 ciphers and as a result this particular scan shows BEAST as not mitigated again because we only have CBC ciphers.  BEAST has been mitigated in all major browsers for a couple years now though so I assume that’s why it is not flagged “vulnerable” like POODLE is.

With Certicom we could add

<ciphersuite>TLS_RSA_WITH_RC4_128_MD5</ciphersuite>
<ciphersuite>TLS_RSA_WITH_RC4_128_SHA</ciphersuite>

at the top of the cipher suite list to put RC4 back in if we wanted which would cause BEAST to report as mitigated server side again.  But again, that only works with Certicom because JSSE does not have server side preference for ciphers yet.  So if you are on PeopleTools 8.51 and using Java 6 perhaps Certicom has the upper hand due to the server cipher order preference.

A scan for JSSE Java 7 looks like this regardless of Weblogic version except for the Secure Client-Initiated Renegotiation, this particular one is from Weblogic 12.1.2 as we see the client-side renegotiation is supported.

When using JSSE with Java 7 you can specify a higher minimum TLS version than 1.0.  If you had tight control of your environment you could even force TLSv1.2 only.  You would use

-Dweblogic.security.SSL.minimumProtocolVersion=TLSv1.2

to set the minimum TLS version used by the Weblogic to TLS 1.2.  This however has the potential to break a few things so it would need to be considered carefully.  Users with new browsers may not see problems, but integrations and other communications could be impacted.

Next I will be sharing some of my analysis of internal PeopleSoft functionality that may be using configurations for HTTPS such as report posting, the IB gateway, outbound IB traffic, etc.  Consider this statement from the JSSE documentation:

Although SunJSSE in the Java SE 7 release supports TLS 1.1 and TLS 1.2, neither version is enabled by default for client connections.

Also I just recently saw this announcement:

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.

The client side analysis is online now.