Enhanced Security with JSSE/JCE on WebLogic

Dan Iverson

We are setting up some new web servers and need to implement strong security on them. By default, a fresh PIA install on WebLogic 11g (compatible with 8.50-8.53) will have SSL enabled, weak ciphers, and missing the full strength cryptography libraries. For a secure web server, we’ll want to make a few changes WebLogic’s HTTPS configuration. Until WebLogic 12.1.1, SSL was handled by the Certicom implementation. In older versions of WebLogic, Certicom cannot handle more than 128-bit keys. Instead, we can use JSSE – Java Secure Socket Extension instead for handling SSL in WebLogic. JSSE and JCE allow WebLogic to use stronger keys and cipher suites than Certicom. We’ll also update our Java version on the web server. The newer Java patches include security changes (like disabling SSL) and we want to stay up-to-date. Let’s walk through the security changes on our web server.

Enable JSSE

If you are on WebLogic 10g or 11g, need to enable JSSE in WebLogic. By default, those versions of WebLogic use the Certicom SSL implementation and we want to get off that implementation. To enable JSSE:

1. Open the WebLogic console and log in.
2. Click the “Lock & Edit” button.
3. Navigate to Environment > Servers > PIA > Configuration > SSL.
4. Click on the “Advanced” section to expand.
5. Select the box for “Use JSSE SSL”.
6. Click “Save”.
7. Click “Activate Changes” to write the configuration changes to file.

Java Version

If you are using Java 6 with your WebLogic installation, you can only support TLS 1.0 (and SSL). To get TLS 1.1 and TLS 1.2 support, you need to upgrade to Java 7 or newer. The newer Java patches also disable SSL support, which is a good thing! To change the version of Java WebLogic uses, you modify the

%PIA_HOME%\bin\setEnv.bat script. Find this comment in the file, @REM JAVA_HOME is set via commEnv.sh, to override set it here. and add this line below the comment.

set JAVA_HOME=e:\java\jdk-1.7.0_xx

You can add this to the WebLogic base commEnv.bat script, but that affects all WebLogic installs on your server. If you only run one instance, that might work for you. But if you run more than one WebLogic PIA instance you’ll want to update the setEnv.bat file for each environment so you can control when the change happens and test it accordingly.

Add JCE Libraries

The JDK delivered with WebLogic (and any JDK you download), has limited strength cryptography libraries (e.g, no AES-256 support). To take full advantage of newer encryption, you need to download the JCE Unlimited Strength Jurisdiction Policy Files.

1. Copy the 2 files, local_policy.jar and US_export_policy.jar, into %JAVA_HOME%\lib\security.
2. Reboot the web server for the changes to take effect.

After these changes, WebLogic will be using a new SSL implementation (JSSE) and support new encryption strengths, like AES-256, giving you access to stronger certificates.

Disable SSL (Use Only TLS)

After the recent SSL vulnerabilities, it is important to disable SSL on your web servers and only use TLS (preferably TLS 1.2 only, if you can). To disable SSL in WebLogic, add this to your %PIA_HOME%\bin\setEnv.bat script in your PIA domain. Find the JAVA_OPTIONS line and add this to the end:

-Dweblogic.security.SSL.protocolVersion=TLSv1

This command tells WebLogic to disable SSL support and use only TLS 1.0, 1.1 or 1.2. It will start with TLS 1.2 if the client supports it, and work back to TLS 1.0. If the client doesn’t support TLS 1.0, their browser will display an error. All modern browsers support at least TLS 1.0 so this shouldn’t be an issue. You can also list a minimum supported version by adding this to the JAVA_OPTIONS line:

-Dweblogic.security.SSL.minimumProtocolVersion=[protocol]

where [protocal] can be

• TLSv1
• TLSv1.1
• TLSv1.2

For more information on how this flag works, you can check out the documentation.

Remove Weak Ciphers

WebLogic ships with many different cipher suites. Ciphers are the algorithms used to encrypt the data between your web server and the client. When an HTTPS connection is started, the client and the server negotiate on what cipher to use. When they find a cipher that both systems support, the connection will use that cipher. One of the attacks with POODLE was to force the server to use a weak (aka, crackable) cipher, so we want to limit the ciphers WebLogic will offer during negotiation.

First, by switching to JSSE, you get some protection. JSSE doesn’t allow Null Ciphers (the Certicom implementation does). Second, you can give WebLogic a list of cipher suites to offer when it negotiates an HTTPS connection. To configure that list, you add ciphers to the config.xml file in the “SSL” section. For example,

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

The list of cipher suites JSSE supports are documented here. Adding in JCE libraries will give you AES256 support as well so you can run support strong ciphers! If you list ciphers in the config.xml file, WebLogic will only offer those ciphers during the HTTPS session negotiation. If the client doesn’t support those ciphers, the connection will fail. So, make sure you test your connection to WebLogic if you add to this list!

To prevent POODLE attacks, [don’t list any “CBC” ciphers] in the cipher suite section (http://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability).

Other Resources

These changes, along with a valid SSL certificate, will give you a secure WebLogic installation. In the resources below, make run your web server though the Qualys SSL Test. That test will grade your web server and show you if you missed anything. This site is a great resource too if a new vulnerability is released; you can re-run the test on your web servers to see if you are impacted.

• Randy over at the Remote PS Admins blog has a great write-up on securing a default WebLogic installation.
• The WebLogic SSL Configuration documentation from Oracle.
• The Qualys SSL Server Test: Enter your publicly accessible URL to test and grade your public web server HTTPS implementation.

Note: This was originally posted by Dan Iverson and has been transferred from a previous platform. There may be missing comments, style issues, and possibly broken links. If you have questions or comments, please contact [email protected].