Disabling SSL 2.0/3.0 and enabling TLS 1.0 or higher in Weblogic 10.3.6 & JDK 7

SSL in Weblogic

Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a network to authenticate each other's identity and by encrypting the data exchanged between the applications.

SSL in WebLogic Server 10.3.6 is an implementation SSL 3.0 and Transport Layer Security (TLS) 1.0 specifications.

Certicom is currently the default SSL implementation in Weblogic Server.

JSSE may be enabled as an alternative SSL implementation.

So why disable SSL 2.0/3.0?

Oracle WebLogic Server should configured exclude SSL 2.0 and/or SSL 3.0 to in order to mitigate the Poodle vulnerability. This often comes as a direction from security teams. The recommended protocols are TLS 1.0 and preferably TLS 1.2 which is more recent.

What protocol to use if not SSL 2.0/3.0?

Transport layer Protocol (TLS) 1.0 and preferably 1.1 or 1.2.

Key Question 1 - So what configurations would a Middleware Admin make to disable SSL V2/V3 support on Weblogic and enable TLS protocols which are safer and recommended by Oracle?

Key Question 2 - How do we enable Weblogic to use TLS 1.0 and above SSL protocol for inbound and outbound connections?

Let’s try and answer it.

Now assuming the Weblogic version is 10.3.6 and JDK used is 1.7 plus below is some facts to know and consider before making changes.

•      Before 10.3.3 (11g), Certicom SSL was the only SSL implementation.

•      In 10.3.3 thru 10.3.6 (11g), Certicom SSL is the default SSL implementation, with JSSE available by enabling a property switch.

•      TLS 1.1 and 1.2 is supported with a combination of JDK 7 Update 1 (or later) and JSSE enabled

•      TLS 1.0 is supported on all releases using either Certicom or JSSE implementation

•      Weblogic Server versions 10.3.6 and 12.1.1 and later are certified with JDK 7 in order to enable JSSE and TLS 1.1/1.2

Inbound

Dweblogic.security.SSL.protocolVersion=TLS1

The interpretation of this property is different depending on whether the Certicom or JSSE implementation is used.

q For Certicom, setting -Dweblogic.security.SSL.protocolVersion=TLS1 enables only TLS 1.0.

q For JSSE, setting -Dweblogic.security.SSL.protocolVersion=TLS1 enables any protocol starting with "TLS", for example TLS 1.0, TLS 1.1, and TLS 1.2.

You may also disable older protocols by configuring a higher minimum protocol. For example, to gain TLS 1.1 and 1.2 support, (if supported by the JDK version), use the following as a JAVA_OPTION:

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

Outbound

 To enable it, you need to use the following -D flags :

       -Dhttps.protocols="TLSv1.2“

Or as a list of choices (handshake is first attempted at the highest level protocol):

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

You may also disable older protocols by configuring a higher minimum protocol.

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

You may also have applications running as a client, (e.g. web services, scripts, or command line) for an outbound ssl connection. Within a Fusion Middleware environment there are also internal processes running where an ssl connection is made, (e.g. OPMN, DMS, EM/FMW Control). To control the outbound connections the following system property is available:

       -Djdk.tls.client.protocols=TLSv1.0,TLSv1.1,TLSv1.2

Hope this post has been helpful to you. I have tried answering the two questions I put to start our discussion.

For understanding the changes needed for disabling SSL V2/3 or enabling TLS on Weblogic 12C/JDK8 please refer here

Made the above changes and still not able to connect using TLS 1.2? Do you get the below error ? 

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

In case yes please refer to to the solution here.

Please feel free to ask any questions you may have in the comment section. Keep learning and spread the word! 

Soumya

TLS Support on Weblogic 12C & JDK8

SSL in Weblogic

Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a network to authenticate each other's identity and by encrypting the data exchanged between the applications.

SSL in WebLogic Server 12.1/12.2 is an implementation of the Transport Layer Security (TLS) 1.2 specifications (backward compatible hence 1.0 & 1.1 supported)

JSSE is currently the default SSL implementation in Weblogic Server. (Certicom deprecated and supported in Weblogic 10.3.6)

So why are we having this discussion?

Oracle WebLogic Server should configured exclude SSL 2.0 and/or SSL 3.0 to in order to mitigate the Poodle vulnerability. This often comes as a direction from security teams. There were configurations needed to be done on Weblogic 10.3.6 and JDK7 installs to exclude these protocols. 

So are there any such configurations needed to be done for Weblogic 12c (12.1 & 12.2) installed with JDK 8? For Weblogic 10.3.6 and JDK 1.7 please refer to my post here.

So what’s the answer?

The answer is NO. Let’s talk in a bit detail here. I will be talking about both Inbound and Outbound connections.

Inbound

• JDK 8 will use TLS 1.2 as default (No external setting needed) 
• Supports TLS 1.0/1.1 as well – (backward compatible)
• You may also disable older protocols by configuring a higher minimum protocol. For example, to gain TLS 1.1 and 1.2 support, (if supported by the JDK version), use the following as a JAVA_OPTION:

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

Outbound

• The JDK 8 default allows both TLS 1.1 and 1.2 by default. 
• You may also set a minimum by removing the older versions, but it is important to consider the external servers the application is connecting to
• The protocol will always be negotiated to the highest supported level between the client and server.
• Set a minimum by removing the older versions as shown below (let's say you want to not support TLS 1.0).

         -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2

So in short if your,Weblogic/JDK versions are 12.2.1/1.8,the default SSL implementation is JSSE and the default TLS version supported is TLS 1,2.TLS 1.0/1.1 are also supported (since backward compatible). 

Hence unlike Weblogic 10.3.6/1.7 we need to set no extra JAVA parameters to disable SSL V2/V3.Use above parameters highlighted in yellow only if you want to restrict certain older TLS versions. The 12C/JDK1.8 install will support all TLS versions (1.0 to 1.2). The protocol will always be negotiated to the highest supported level between the client and server.

Please feel free to ask any questions you may have in the comment section. Keep learning and spread the word! 

Soumya

Connection Testing cannot be enabled for a pool when the ManagedConnectionFactory does not implement ValidatingManagedConnectionFactory

Applies To: Oracle SOA Suite/Weblogic 10g,11g,12C

I was trying to set below set below JCA Adapter connection pool properties to true. The values I was setting them to is mentioned below.

Test Frequency Seconds: 300 (Default 0)
Test Connections On Reserve: True (Default False)

I was trying to set it for a Oracle MQ Series connection pool. The customer reported that the MQ adapter stop picking message from the Websphere MQ once the system went down for maintenance e.g. queue manager unavailable. After confirming the MQ system was up and running the connecting SOA interface/composite had to be restarted to make the system pick messages. With my past experience with datasource connection pools I thought I could fix this issue by forcing the adapter to validate connections to MQ system periodically. I could easily achieve this by setting above connection pool parameters. Ideally above setting mean that the MQ connection pool checks for the MQ system to be present every 300 seconds and only passes valid connections to application when it tries to reserve a connection to the MQ system. Theoretically I got it all figured out until I applied the settings and the logs reported below issue ! 


weblogic.management.DeploymentException: Connection Testing cannot be enabled for a pool when the ManagedConnectionFactory does not implement ValidatingManagedConnectio
 nFactory. The following invalid settings have been detected:test-frequency-seconds is set to non-zero
   [Connector:199167]test-connections-on-reserve is set to true


The adapter would not come up till I reverted my settings back ! So what happened? 

On further research (googling of course) I could find that only if a resource adapter's ManagedConnectionFactory implements the ValidatingManagedConnectionFactory interface, then the application server can test the validity of existing connections. Refer to Testing Connections section here. 

 As per Oracle Metalink doc ID 957853.1 Oracle MQ adapter does not use above stated interface hence as per the error in logs connection validity can't be tested ! Hence enabling connection test setting like below for the MQ series adapter won't work as expected and you will get above mentioned error.

Test Connections On Create:
Test Connections On Reserve:
Test Connections On Release:

So now the question remains, is there a way we can work around this known limitation? Well I think it is possible. Oracle Metalink doc ID 957853.1  declares this issue as Bug 8913481 & Bug 8918056. The note prescribes applying patch 8918056 (MQAdapter fix) to fix above explained issue. But the patch applies to older version of BPEL (10.1.3.4) 

I would encourage you to present this analysis to Oracle and request a patch for above mentioned bugs for newer versions of Oracle SOA Suite/Middleware like 11g/12C. I got the above issue on Oracle SOA Suite version 11.1.1.7.8. I reached out to Oracle and they asked me to apply the patch for bug 21689260.

On a side note this issue is also relevant for other Oracle adapters available with SOA Suite. As per Oracle Metalink Doc ID 1282064.1 testing of the Apps adapter and DB adapter connection factories via the WebLogic console is not supported since the ManagedConnectionFactory of both adapters does not implement ValidatingManagedConnectionFactory due to performance considerations (during runtime) and due to the fact that the DB/Apps JCA connection is just a shallow wrapper around a data source connection handle.

Soumya Mishra