SOLUTION

What Ciphers Will be Used By Default?

A few factors determine what ciphers will be used in an SSL connection - On the server side, it would first depend on the WLS version if JSSE is enabled or not, (as opposed to Certicom) and the JDK version in use. Different JDK versions have different cipher suite allowances due to updated industry standards. In addition, one may have the Java Cryptography Extension (JCE) for the absolute highest strength (e.g. all 256 bit). If the JDK is a currently supported release, maintaining to the latest _xx (specific changes may occur with each version) will remove older anonymous/null ciphers and only use 128-bit or higher industry accepted ciphers.  All of the aforementioned factors impact the list of available ciphers supported on the server side. Based on that list, it is actually negotiated with the client requesting connection (which its own list of supported ciphers) during the ssl handshake. That has the final say on what cipher is actually used.

WLS can be configured (e.g. config.xml) for specific ciphers, but is normally only configured if needing to explicitly state one or few ciphers because you know what the client (which can also be internal connections and from other servers) accepts; or business requirements need that narrowed down list for whatever reason. Sometimes ciphers are manually configured because JSSE isn't enabled and the JDK isn't updated (on purpose or unknowingly). If you decide that you need more control over the cipher list supported by the server, then you can manually configure after checking that all potential clients also accept it, else there will be handshake errors.

Compatibility Warning

Adding custom ciphers can break functionality of internal components. Be very careful and test your applications and Oracle provided applications. As a general rule it is not advisable to update the default ciphers until after you have updated to newer WLS, JDK, enabled JSSE and applied CPU/PSU patches. These actions all have an affect on the default ciphers, available ciphers and cover known security issues. Integrated Fusion Middleware products have CPU patches which update ciphers they accept.

Notes:

·          

o    If after applying CPU/PSU patches available for your version, if you see the use of an older, weak, or insecure cipher, please ensure an SR and Bug is filed for the component in order to request an update on the default and/or communication on how to disable.

o    If you are looking for SSL Protocol information to coordinate with your cipher requirements see Note 1936300.1 , "How to Change SSL Protocols (to Disable SSL 3.0) in Oracle Fusion Middleware Products".

 

Disable Anonymous and Weak Cipher Suites in Oracle WebLogic Server

The first step should be to modify the default cipher suite used for the best possible security and functionality for your server by enabling JSSE and updating your JDK (Note 1492980.1). Further explanations for each version are below:

In WLS 10.3.6, ciphers may be configured as a JAVA_OPTIONS parameter or in the config.xml (see next section), but there are other important considerations as you maintain this release for other reasons:

The original Certicom SSL implementation is deprecated in favor of enabling JSSE, which uses more current ciphers and allows use of stronger ciphers than Certicom. For a list of allowable cipher suites in both Certicom and JSSE and how to configure, see 10.3.6 Ciphers in the Oracle Documentation. It is preferred that you enable JSSE before making customizations. If you enable JSSE later, you will want to go back and test again for change management reasons.

WLS 10.3.x is shipped with JDK 1.6, which does not disable weaker algorithms under 128-bit. This functionality was delivered in JDK 1.7 Update 40.  JDK 1.7 is supported with WLS 10.3.6, so that is an option for eliminating the weaker algorithms with lower encryption. If you update the JDK later, you will want to go back and test again for change management reasons. See  Note 1492980.1 - "How to Maintain the Java SE Installed or Used with FMW 11g/12c Products". Continually updating your JDK will ensure you have the latest defaults in respect to SSL protocols and ciphers.

To allow the Node Manager to use stronger ciphers, WebLogic Server version must be at least 10.3.6.0.10 or newer, (PSU initially delivered January 2015).

Until such time you upgrade to 12c, it is suggested to be on version 10.3.6, apply the latest PSU 10.3.6.0.10 (or newer), enable JSSE and if certified for other products and applications, use the latest JDK 7 Update 40 (or above). Note not all FMW products are certified with JDK 7, but latest JDK 6 may be applied. If there are further issues with undesirable ciphers, it should be reported to WLS Development and Oracle Security to consider the best direction forward. If you are certain all desired SSL clients are capable of using a desired cipher, you may configure as documented. Note that "SSL clients" may include your expected clients, other Oracle products, or internal FMW components installed in your environment.

 

In WLS 12c releases, the recommendations are aligned with the WLS 10.3.6 and higher statements above, however JSSE is enabled by default. Refer to 12c Ciphers in the Oracle Documentation for updates. To allow the Node Manager to use stronger ciphers, WebLogic Server version must be at least 12.1.1.0.10, 12.1.2.0.4  or 12.1.3.0.2 (PSUs initially delivered January 2015 for versions under error correction support). By default you should not require to update the ciphers for null or under 128 bit, although the JAVA_OPTIONS or in the config.xml may be used to customize ciphers. Caution should be used to discover all client supported ciphers, noting the client may be other middleware processes.

 

Important: 

- Newer Java versions have disabled older and weak ciphers by default. See Note 1492980.1 for download locations and steps to update. 

- RC4 ciphers are a suite of ciphers having been removed. See JDK 1.7.0_85 Release Notes and JDK 1.6.0_101 Release Notes. If you have explicitly configured WLS with ciphers such as TLS_RSA_WITH_RC4_128_SHA or TLS_RSA_WITH_RC4_128_MD5, (which have been very popular in the past), you may see errors after updating the JDK:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
javax.net.ssl.SSLException: Received fatal alert: handshake_failure

You should then remove those ciphers from your configuration and configure a new cipher according to a WLS Documentation for your version. If you are on a newer WLS version supporting the newer JDK version with JSSE enabled, you should not require explicit configuration of ciphers (e.g. in config.xml) unless your business requirements need more specific settings.

 

 

Manually or Explicitly Configuring Ciphers

There may be a need to explicitly configure a cipher or cipher list depending on your version, business decisions and other requirements. You can and should explicitly disable ciphers which support clear text communication. The server allows clear text communication either because strong cipher suites are not specified or null cipher suites are specified. To prevent clear text communications, avoid ciphers such as TLS_RSA_WITH_NULL_MD5 and TLS_RSA_WITH_NULL_SHA, as these have 0 Symmetric Key Strength. Refer to the Oracle Documentation specific to your version for which ciphers are supported.

On older 10.3 versions without a newer JDK update, if no cipher suite is specifically mentioned in the config.xml file, then the cipher suites that allow clear text communication may be enabled. To disable these clear text cipher suites, set the following as JAVA_OPTIONS during startup:     

          -Dweblogic.security.disableNullCipher=true
          -Dweblogic.security.SSL.allowUnencryptedNullCipher=false

For all versions, the domain's config.xml file may also be configured for the cipher suite that you want to use. To specify a cipher suite, add the below attributes and specify any cipher suites as needed (and as supported by both sides of the communication to establish a handshake):

For example:

 In WLS 10.3.x and 12c, you may add the tag in the config.xml with ciphers you wish to use:

     Ensure is added before the as below for admin and managed servers:

         
                AdminServer
                true
                enter_a_cipher_of_your_choice_here
                enter_another_optional_cipher_of_your_choice_here
                7002
                25000
                ...     

        You may have the Admin Server with a "false" setting because of this documentation. You edit the same way, usually only because something is detecting an undesirable cipher.   

 

 In WLS 9.x and higher, set desired ciphers in config.xml supported by this version and JDK in use:

      Between AdminServer and add

     
      true
      enter_a_cipher_of_your_choice_here
      enter_another_optional_cipher_of_your_choice_here
     
 

In WLS 8.1, set it in config.xml as using ciphers supported by this version and JDK in use:

     Ciphersuites="enter_comma_delimited_cipher_list_here"


Note: The goal should be to configure a cipher of your choosing, as supported by the Oracle Documentation and any clients connecting which are not null, anonymous or under 128-bit encryption. Configuring with custom ciphers may produce unpredictable results between different components. Ensure documentation is followed and give time to test across your environment. You should always follow the Critical Patch Update (CPU) program concerning security vulnerabilities. If following the CPU program for versions under Error Correction Support, you may not actually need to explicitly configure ciphers unless you have other business requirements to do so.

 

Certificate Key Strength Greater than 1024

You may need to update your certificate key strength to greater than 1024. Newer JDK versions will limit this, see the following:

Note 1607170.1 SSL Authentication Problem Using WebLogic 10.3.6 and 12.1.1 With JDK1.7.0_40 or Higher and JRockit R28.3.7
Note 2097194.1 Impact of Jan 19, 2016 JDK CPU Updates on SSL/TLS and WLS 10.3.6 Demo Certificates - WLS 10.3.6 w/SSL
 

SHA-256

Related and looking towards the future, the industry standard is increasing to use SHA2.  See the following for the support status of using SHA2 with Oracle Fusion Middleware products:

Note 1275428.1 Support Status for SHA2 in Oracle Fusion Middleware 11g/12c (including Weblogic Server) and Oracle Application Server 10g (10.1.2/10.1.3/10.1.4)

 

Node Manager

To allow the Node Manager to use stronger ciphers, WebLogic Server version must be at least 10.3.6.0.10, 12.1.2.0.4  or 12.1.3.0.3 (which are PSU versions delivered early 2015, see Note 1470197.1 for the latest). The nodemanager.properties may be used to customize ciphers, but will not work correctly with Node Manager unless the PSUs are applied. After the PSU is applied and JDK updated, it is recommended to allow the default processing take place. Caution should be used if setting this manually. You will need to discover all supported ciphers the node manager will need to handshake with, noting it may be other internal middleware processes. By default you should not require to update the ciphers for null, under 128-bit, weak, or vulnerabilities if you are updating the JDK and applying PSUs.  It is not recommended to configure unless you have a strict business requirement to use only one cipher as below:

In the nodemanager.properties

CipherSuite=enter_a_cipher_of_your_choice_here  

Note: 

a) The cipher you choose must begin with SSL_ (even if using TLS) and must be compatible with other entities requiring a connection (e.g. other Fusion Middleware tools and components)

b) You can only configure a cipher which is supported by the JDK you have installed (and certified with WLS):
      https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
      https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
      https://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider

c) Check other JAVA_OPTION settings you may have configured earlier which could conflict with this.