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.

SSL test WLS1036 default protocol
SSL test WLS1036 default protocol details

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.

SSL test WLS1036 default ciphers

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.

SSL test WLS1212 default protocol

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

SSL test WLS1212 default protocol details

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.

SSL test WLS1212 default ciphers

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!

SSL test WLS1036 JSSE protocol
SSL test WLS1036 JSSE protocol details

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

SSL test WLS1036 JSSE ciphers

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.

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

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

SSL test WLS1036 default no SSL3 protocol
SSL test WLS1036 default no SSL3 protocol details

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.

SSL test WLS1036 default no SSL3 secured ciphers
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.

SSL test WLS1036 default no SSL3 secured protocol details
With Certicom we could add

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.
SSL test WLS1212 default no SSL3 protocol SSL test WLS1212 default no SSL3 protocol details

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

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.

16 thoughts on “SSL and Weblogic
  1. Thanks for a very helpful article. We’ve been reviewing our cipher suites using it as a starting point, and found that Weblogic 10.3.6 using JSSE, with a 7u76 JDK can support the following;


    (We didn’t test known weak cipher suites, or RC4 cipher suites). It seems to be everything from the Java JCE documentation, excepting any cipher suites that use GCM).

  2. Thanks for the detailed Explanation, That is very helpful.

    I have a question, Recently we have disabled SSLv3 in our Weblogic Env and enabled TLS1.0 by adding the property value in file. After restarting the Admin server, we are able to check it from the console output that its running on TLS1.0 now.

    My doubt here is, How can we know that the managed servers are using TLS1.0 too ? Is there anyway we can verify that ? OR do we have to add that property value to the Managed server start up parameters as well.

    Thanks in Advance !

  3. The explanation is really good and step by step.
    It helped me in fixing few vulnerabilities and made me gain more knowledge.

    • This post covers that pretty well. If you want to set TLS1.1 as the minimum version you would use assuming you are using Java 7 and JSSE impelementation. Neither the delivered Certicom or Java 6 configurations support beyond TLS1.0.

Leave a Reply

Your email address will not be published. Required fields are marked *