IBM Support

IBM SDK, Java Technology Edition fixes to mitigate against the POODLE security vulnerability (CVE-2014-3566)

News


Abstract

Fixes are provided with the IBM SDK, Java Technology Edition to mitigate against the Padding Oracle On Downgraded Legacy Encryption (POODLE) vulnerability on Secure Socket Layer (SSL) V3.0. In order to mitigate this vulnerability, the SSL V3.0 protocol must not be enabled. The IBM SDK has been updated to disable SSL V3.0 automatically. These fixes implement a significant change in default behavior that will cause failures in any applications that rely exclusively on SSL V3.0. Note: Further changes apply following the Oracle January 2015 security update.

Content


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:

Protocol label Protocol enabled before the fix Protocol enabled after the fix
SSL SSL V3.0 Varies per release of the SDK. See the next table.
SSLv3 SSL V3.0 None, the connection fails.
TLS TLS V1.0 (defined in RFC2246) TLS V1.0 (defined in RFC2246)
TLSv1 TLS V1.0 (defined in RFC2246) TLS V1.0 (defined in RFC2246)
TLSv1.1 TLS V1.1 (defined in RFC4346) TLS V1.1 (defined in RFC4346)
TLSv1.2 TLS V1.2 (defined in RFC5246) TLS V1.2 (defined in RFC5246)
SSL_TLS Enables all SSL V3.0 and TLS V1.0 protocols TLS V1.0
SSL_TLSv2 Enables all SSL V3.0 and TLS V1.0, V1.1, and V1.2 protocols TLS V1.0, V1.1, and V1.2 protocols


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

SDK version
TLS V1.0
TLS V1.1
TLS V1.2
Java 7 server
*
*
*
Java 7 client
*
Java 6.0.1 (J9 VM2.6)
*
Java 6
*
Java 5.0
*
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:

jdk.tls.disabledAlgorithms setting com.ibm.jsse2.disableSSLv3 setting SSL V3.0 status
SSLv3 (default) true (default) Disabled
SSLv3 (default) false Disabled
No value set (SSLv3 removed) false Enabled
No value set (SSLv3 removed) true (default) Disabled

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:

Current usage
Suggested change
SSLContext.getInstance()       SSLContext.getInstance("TLSv1")
SSLEngine.setEnabledProtocols() engine.setEnabledProtocols(new String[] {"TLSv1"});
SSLSocket.setEnabledProtocols()   socket.setEnabledProtocols(new String[] {"TLSv1"});
    SSLServerSocket.setEnabledProtocols()       serverSocket.setEnabledProtocols(new String[] {"TLSv1"});

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:

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

Document information

More support for: Runtimes for Java Technology
Java SDK

Software version: 5.0, 6.0, 7.0, 7.1

Operating system(s): AIX, HP-UX, Linux, Solaris, Windows, z/OS

Software edition: Java SE

Reference #: 1688165

Modified date: 22 January 2015


Translate this page: