The POODLE security vulnerability applies to any application that uses SSL/TLS under one of the following conditions:

• The application uses a protocol configuration that enables SSL and TLS, which might fall back to SSL V3.0.
• The application explicitly allows or requests SSL V3.0.

For example, if you have SSL hard-coded in your application code, such as SSLContext.getInstance("SSL"), the current implementation defaults that context to SSL V3.0. To secure your application against the vulnerability, the following enhancements are made to the IBM SDK:

• SSL V3.0 is disabled by default and the TLS protocols are enabled, as shown in the tables.
• A new system property is provided that allows you to reenable SSL V3.0. However, your application is exposed to this security vulnerability. See Alternative mitigation options.

The following table lists some common protocol label names that are used by the IBM SDK and the change in protocol that is enabled with this fix:



When the protocol label SSL is used, the following TLS protocols, marked with an asterisk (*), are enabled per release of the SDK:

If you must enable SSL V3.0, a new system property is provided. Set the following system property either statically or dynamically:

com.ibm.jsse2.disableSSLv3=false

The SSL V3.0 protocol is not allowed when the IBM JVM is configured to run in either FIPS 140-2 mode or SP800-131a in transition or strict compliance mode. Therefore, these modes are not susceptible to the POODLE attack.

FIPS 140-2 mode is specified by using one of the following system properties:
• com.ibm.jsse2.usefipsprovider=true
• com.ibm.jsse2.JSSEFIPS=true
For more information, see Running IBMJSSE2 in FIPS mode.

NIST SP800-131a transition or strict compliance is specified by using the system property:
• com.ibm.jsse2.sp800-131=[strict|transition]
For more information, see SP800-131a compliance.

The fixes for this vulnerability are implemented in the following releases of the SDK and Runtime Environment on all platforms, including Solaris and HP-UX:

• IBM SDK, Java Technology Edition, Version 7 Release 1 Service Refresh 2
• IBM SDK, Java Technology Edition, Version 7 Service Refresh 8
• IBM SDK, Java Technology Edition, Version 6.0.1 Service Refresh 8 (J9 VM2.6) Fix Pack 2
• IBM SDK, Java Technology Edition, Version 6 Service Refresh 16 Fix Pack 2
• IBM SDK, Java 2 Technology Edition, Version 5.0 Service Refresh 16 Fix Pack 8

Following this change, if your application attempts to use SSL V3.0, the application fails to negotiate a session. The failure might be manifested in different ways and might not immediately point to an SSL connection error. To help you diagnose problems, see Diagnosing failures.

If you are unable to upgrade immediately to these levels, some suggestions are provided to temporarily secure your applications against the vulnerability. See Alternative mitigation options.


In the Oracle January 2015 security update, this vulnerability is addressed by using a security property. There is a change to the Oracle security property jdk.tls.disabledAlgorithms to address the POODLE vulnerability. The default value of this property in the java.security file includes SSLv3, which means that the SSLv3 protocol is not allowed. You can modify the setting to remove SSLv3 or add further algorithms with the following syntax:

jdk.tls.disabledAlgorithms = <Algorithm_1>, <Algorithm_2>

This property has precedence over the IBM property com.ibm.jsse2.disableSSLv3. The following table shows the effect of setting either the IBM property or the Oracle property, on the SSL v3.0 protocol:


Note: The protocol label name changes apply irrespective of the system property used.

The Oracle changes are in the following releases of the SDK and Runtime Environment on all platforms, including Solaris and HP-UX:

• IBM SDK, Java Technology Edition, Version 7 Release 1 Service Refresh 2 Fix Pack 10
• IBM SDK, Java Technology Edition, Version 7 Service Refresh 8 Fix Pack 10
• IBM SDK, Java Technology Edition, Version 6.0.1 Service Refresh 8 (J9 VM2.6) Fix Pack 3
• IBM SDK, Java Technology Edition, Version 6 Service Refresh 16 Fix Pack 3
• IBM SDK, Java 2 Technology Edition, Version 5.0 Service Refresh 16 Fix Pack 9

---

Alternative mitigation options

The following three options are suggested if you are unable to upgrade immediately:

1. From Java 6.0.1 service refresh 7 (J9 VM2.6), Java 6 service refresh 15, Java 7 service refresh 1, and later SDK versions, the default protocol settings can be overridden to disallow SSL V3.0. For more information, see Overriding the SSL protocol defined by the default SSL socket factory.

2. If your application uses  javax.net.ssl.HttpsURLConnection,set the https.protocols system property explicitly to disallow SSL V3.0, which otherwise defaults to allow SSL V3.0. For example, use the following command line option:

• For the initial release of Java 6.0.1 (J9 VM2.6), Java 6 service refresh 9 and Java 5.0:
  -Dhttps.protocols=TLSv1

• For Java 6.0.1 service refresh 1 (J9 VM2.6), Java 6 service refresh 10, and all later releases:
  -Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2"

3. If your application uses javax.net.ssl.SSLSocket or javax.net.ssl.SSLServerSocket, programmatically set the enabled protocol for the socket(s) to one or more of the TLS protocols ( TLSv1, TLSv1.1, TLSv1.2) by using an appropriate API. Choose the best solution for your application. For example:


Note: TLSv1.1 and TLSv1.2 are available only for Java 6 service refresh 10, Java 6.0.1 service refresh 1 (J9 VM2.6), and later releases.

For more information, read the following related topics in the IBM Knowledge Center:

• SSLContext class
• SSL protocols

Go back to top  

---

Diagnosing failures

If SSL V3.0 is the only protocol requested, an IllegalArgumentException exception is seen when there is an attempt to create a secure server socket. For example:

java.lang.IllegalArgumentException: Only SSLv3 was enabled while com.ibm.jsse2.disableSSLv3 is set to true
    at com.ibm.jsse2.pb.a(pb.java:32)
    at com.ibm.jsse2.pb.<init>(pb.java:2)
    at com.ibm.jsse2.oc.a(oc.java:60)
    at com.ibm.jsse2.oc.<init>(oc.java:66)
    at com.ibm.jsse2.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:8)
    ...

If the SSL V3.0 protocol is specified as an alias on the SSLContext.getInstance, a NoSuchAlgorithmException exception occurs.

A connection attempt might also be rejected under the following conditions:

• On the server side of the connection:
  • SSL V3.0 is one of a number of protocols specified, for example, as part of the default list of protocols.
• On the client side of the connection:
  • Only SSL V3.0 is supported.

Under these conditions, a SSLHandshakeException exception is seen on the server, similar to the following example:

javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 not enabled or not supported
    at com.ibm.jsse2.j.a(j.java:36)
    at com.ibm.jsse2.qc.a(qc.java:98)
    at com.ibm.jsse2.ab.a(ab.java:445)
    at com.ibm.jsse2.ab.a(ab.java:165)
    at com.ibm.jsse2.cb.a(cb.java:614)
    at com.ibm.jsse2.cb.a(cb.java:676)
    at com.ibm.jsse2.ab.s(ab.java:124)
    at com.ibm.jsse2.ab.a(ab.java:122)
    at com.ibm.jsse2.qc.a(qc.java:118)
    at com.ibm.jsse2.qc.h(qc.java:498)
    at com.ibm.jsse2.qc.a(qc.java:99)
    at com.ibm.jsse2.qc.startHandshake(qc.java:311)

A SSLHandshakeException exception is seen on the client, similar to the following example:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    at com.ibm.jsse2.j.a(j.java:36)
    at com.ibm.jsse2.j.a(j.java:25)
    at com.ibm.jsse2.qc.b(qc.java:183)
    at com.ibm.jsse2.qc.a(qc.java:579)
    at com.ibm.jsse2.qc.h(qc.java:498)
    at com.ibm.jsse2.qc.a(qc.java:99)
    at com.ibm.jsse2.qc.startHandshake(qc.java:311)  

Go back to top