Regressions due to USN-2696-1

Also affects JDK6; the situation is a little worse on 6, which does not support anything newer than TLS1.0

Issue JDK-4873188 [1] asked for TLS 1.1 support for OpenJDK 1.4, 5, 6, and 7. It was implemented for OpenJDK 7 [2] and recently backported to 6 [3].

An issue to add TLS 1.2 support to OpenJDK 1.4, 5, and 6 was tracked by JDK-6916074 [4], but support for it was only added for OpenJDK 7 [5].

It is not clear at this time if TLS 1.2 is supported by OpenJDK 6. The TLS 1.1 backport [3] seems to have integrated TLS 1.2 support code (but with a seemly hard-coded max for TLS 1.1) and a fix for a TLS 1.2 bug was recently incorporated [6] which includes a test for "SSLv3", "TLSv1", "TLSv1.1", and "TLSv1.2".

JDK-7093640 [7] tracked the effort to enable TLS 1.2 by default for OpenJDK 7 and 8, but was only enabled for OpenJDK 8 [8] and 9 [9]. The rationale at the time [see 7] was to keep it disabled for OpenJDK 7 due to existing "version intolerant" servers - ie. "TLS server deployments that do not accept higher TLS version numbers, which is generally version TLS v1.0".

As for RC4, disabling it was originally reported in JDK-8076221 [10] and executed by S8043202. For OpenJDK 7, that change was integrated into IcedTea 2.5 JDK forest [11] and released in 2.5.6 [12] and 2.6.1 [13]. OpenJDK 6 got it in IcedTea 1.13.8 release [14].

References:
[1] https://bugs.openjdk.java.net/browse/JDK-4873188
[2] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/93cd7e89adb8
[3] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0ddb5d39438d

[4] https://bugs.openjdk.java.net/browse/JDK-6916074
[5] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9d6a9f65d2bf

[6] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/042e39055298

[7] https://bugs.openjdk.java.net/browse/JDK-7093640
[8] https://bugs.openjdk.java.net/browse/JDK-8031273
[9] https://bugs.openjdk.java.net/browse/JDK-8030791

[10] https://bugs.openjdk.java.net/browse/JDK-8076221
[11] http://icedtea.classpath.org/hg/release/icedtea7-forest-2.5/jdk/rev/0982455b2f4d
[12] http://blog.fuseyism.com/index.php/2015/07/23/security-icedtea-2-5-6-for-openjdk-7-released/
[13] http://blog.fuseyism.com/index.php/2015/07/21/security-icedtea-2-6-1-for-openjdk-7-released/
[14] http://blog.fuseyism.com/index.php/2015/07/30/security-icedtea-1-13-8-for-openjdk-6-released/

Test results suggest that openjdk-6 supports the TLSv1.2 ClientHello but not the new TLSv1.2 cipher suites. The following is from a VM launched with -Djavax.net.debug=all -Dhttps.protocols=TLSv1.2:

openjdk-6-jre-6b36-1.13.8-0ubuntu1~12.04

*** ClientHello, TLSv1.2
RandomCookie: GMT: 1422580230 bytes = { 237, 29, 146, 178, 186, 223, 250, 193, 35, 183, 108, 180, 97, 191, 193, 23, 207, 215, 48, 80, 237, 156, 63, 194, 18, 109, 250, 59 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

Nathan, would you mind sharing the java file and steps to reproduce so I can run a few tests? Thanks!

Stay tuned, I'll have something a little later. In the meantime I found this:

https://bugs.openjdk.java.net/browse/JDK-2210924

(backport request for AEAD ciphers to JDK7 - closed as Won't Fix)

If that remains the decision, it would at least be nice to see the default ClientHello changed from 1.0 1.2 to enable IV workaround

Original discussion of AEAD -

http://mail.openjdk.java.net/pipermail/security-dev/2011-April/003097.html

See this issue to drop RC4 support in the Chromium project: https://code.google.com/p/chromium/issues/detail?id=375342

Lots of good discussion but especially comment #44, #49, and perhaps the real key takeaway is comment #53:

------ quote ------
#53 <email address hidden>
On the topic of PCI and CVSS scores, I talked with a QSA. Because of the 4.3 scores and general badness, PCI 3.1 was released recently and marks TLS 1.0 and below as unacceptable. Anyone wanting to use it must document a Risk Mitigation and Migration Plan. Which people do by saying "We have clients who haven't upgraded." But in newly deployed infrastructure the PCI Council is actually saying that they can't deploy TLS 1.0 or below at all, and to strand any older clients.

I don't imagine this significantly affects opinions on UI treatment (including keeping the EV badging), but wanted to add some context I learned today.

See also: https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information_Supplement_v1.pdf
------ end quote------

Thus, if openjdk-6 and -7 continue to send a TLSv1.0 ClientHello by default, they soon risk losing connectivity to significant portions of the secure WWW. As a PCI compliant shop, this is already an issue here and we have some upcoming deadlines to make some changes.

At the moment, I have seen 3 specific examples of broken connectivity:
(1) web service gateway for an airline reservation system which refuses to negotiate CBC unless protocol level is TLSv1.1 or newer. This site is behind a source-IP based packet filter so I can't have anyone else test against it.
(2) The public-facing internet-booking website for an airline (VA), which refuses to negotiate CBC at all, even on TLSv1.2, and does not support AEAD ciphers. The only option for this one is RC4
(3) The SOAP service endpoint for a payment service provider; this one is a lot like (2) - only RC4. This is also behind a source IP filter

Tiago, under the circumstances, what kind of test code would you like to see? It is not possible to write a pure-Java test client and server which mimics the behavior of example (1), because an SSLServerSocket only enables/disables cipher suites globally across all protocol levels.

I'm not sure what can responsibly be done about examples like (2) and (3), but it seems probably that sites like example (1) will become more common.

I have created OpenJDK 6 packages for Precise and Wily (should run on Vivid as well) with TLS 1.1 enabled by default and a OpenJDK 7 package for Wily with TLS 1.2 enabled by default as well. If you can, please test those and let me know the results.

$ sudo add-apt-repository ppa:tdaitx/openjdk

See repo at https://launchpad.net/~tdaitx/+archive/ubuntu/openjdk

As for RC4, it has been fully disabled upstream now [1,2,3,4]. In particular:
* 8043200: Decrease the preference mode of RC4 in the enabled cipher suite list
* 8050158: Introduce system property to maintain RC4 preference order
* 8043201: Deprecate RC4 in SunJSSE provider
* 8043202: Prohibit RC4 cipher suites

In order to use RC4 it seems that you need to set the system property "jdk.tls.preserveRC4CipherSuites" to "true" and make sure the algorithm you want to use is listed under "jdk.tls.legacyAlgorithms" in the java.security file (for Ubuntu it will be at /etc/java-7-openjdk/security/java.security or /etc/java-6-openjdk/security/java.security). Algorithms in jdk.tls.legacyAlgorithms will be tried only after exhausting all other options.

[1] http://blog.fuseyism.com/index.php/2015/07/30/security-icedtea-1-13-8-for-openjdk-6-released/
[2] http://blog.fuseyism.com/index.php/2015/07/23/security-icedtea-2-5-6-for-openjdk-7-released/
[3] http://mail.openjdk.java.net/pipermail/jdk6-dev/2015-August/003540.html
[4] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-August/010390.html

Here's a small test class and the results from a few different JVMs I have access to:

--- cut here ---
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;

public class TLSVersions
{
  public static void main( String[] args )
  {
    String vendor = System.getProperty( "java.vendor" );
    String version = System.getProperty( "java.version" );

    System.out.println( String.format( "java.vendor\tjava.version\tproto\tenabledProtocols" ) );
    for ( String protocol : new String[]{ "TLSv1.2", "TLSv1.1", "TLSv1", "TLS", "SSL" } )
    {
      try
      {
        SSLContext context = SSLContext.getInstance( protocol );
        context.init( null, null, null );
        SSLSocket socket = ( SSLSocket ) context.getSocketFactory().createSocket();
        String enabledProtocols = join( socket.getEnabledProtocols() );
        System.out.println( String.format( "%s\t%s\t%s\t%s", vendor, version, protocol, enabledProtocols ) );
      }
      catch ( Exception e )
      {
        System.out.println( String.format( "%s\t%s\t%s\t%s", vendor, version, protocol, e.toString() ) );
      }
    }
  }

  private static String join( String[] array )
  {
    if ( array.length == 0 )
    {
      return "";
    }
    StringBuilder sb = new StringBuilder( array[ 0 ] );
    for ( int i = 1; i < array.length; i++ )
    {
      sb.append( ',' ).append( array[ i ] );
    }
    return sb.toString();
  }
}
--- cut here ---

java.vendor or dpkg java.version proto enabledProtocols
Apple Inc. 1.6.0_37 TLSv1.2 java.security.NoSuchAlgorithmException: TLSv1.2 SSLContext not available
Apple Inc. 1.6.0_37 TLSv1.1 java.security.NoSuchAlgorithmException: TLSv1.1 SSLContext not available
Apple Inc. 1.6.0_37 TLSv1 SSLv2Hello,SSLv3,TLSv1
Apple Inc. 1.6.0_37 TLS SSLv2Hello,SSLv3,TLSv1
Apple Inc. 1.6.0_37 SSL SSLv2Hello,SSLv3,TLSv1
Oracle Corporation 1.7.0_80 TLSv1.2 TLSv1,TLSv1.1,TLSv1.2
Oracle Corporation 1.7.0_80 TLSv1.1 TLSv1,TLSv1.1
Oracle Corporation 1.7.0_80 TLSv1 TLSv1
Oracle Corporation 1.7.0_80 TLS TLSv1
Oracle Corporation 1.7.0_80 SSL TLSv1
Oracle Corporation 1.8.0_60 TLSv1.2 TLSv1,TLSv1.1,TLSv1.2
Oracle Corporation 1.8.0_60 TLSv1.1 TLSv1,TLSv1.1
Oracle Corporation 1.8.0_60 TLSv1 TLSv1
Oracle Corporation 1.8.0_60 TLS TLSv1,TLSv1.1,TLSv1.2
Oracle Corporation 1.8.0_60 SSL TLSv1,TLSv1.1,TLSv1.2
6b36-1.13.8-0ubuntu1 1.6.0_36 TLSv1.2 java.security.NoSuchAlgorithmException: TLSv1.2 SSLContext not available
6b36-1.13.8-0ubuntu1 1.6.0_36 TLSv1.1 SSLv3,TLSv1,TLSv1.1
6b36-1.13.8-0ubuntu1 1.6.0_36 TLSv1 SSLv3,TLSv1
6b36-1.13.8-0ubuntu1 1.6.0_36 TLS SSLv3,TLSv1
6b36-1.13.8-0ubuntu1 1.6.0_36 SSL SSLv3,TLSv1
7u79-2.5.6-0ubuntu1 1.7.0_79 TLSv1.2 TLSv1,TLSv1.1,TLSv1.2
7u79-2.5.6-0ubuntu1 1.7.0_79 TLSv1.1 TLSv1,TLSv1.1
7u79-2.5.6-0ubuntu1 1.7.0_79 TLSv1 TLSv1
7u79-2.5.6-0ubuntu1 1.7.0_79 TLS TLSv1
7u79-2.5.6-0ubuntu1 1.7.0_79 SSL TLSv1

6b36-1.13.8-0ubuntu2~ppa2 1.6.0_36 TLSv1.2 java.security.NoSuchAlgorithmException: TLSv1.2 SSLContext not available
6b36-1.13.8-0ubuntu2~ppa2 1.6.0_36 TLSv1.1 SSLv3,TLSv1,TLSv1.1
6b36-1.13.8-0ubuntu2~ppa2 1.6.0_36 TLSv1 SSLv3,TLSv1
6b36-1.13.8-0ubuntu2~ppa2 1.6.0_36 TLS SSLv3,TLSv1
6b36-1.13.8-0ubuntu2~ppa2 1.6.0_36 ...

I should clarify that my tests results for 6b36-1.13.8-0ubuntu1 are based on a modified java.security file which removed SSLv3 from the jdk.tls.disabledAlgorithms property. That may be the reason why they show SSLv3 as a default-enabled algorithm.

Also, I was finally able to test your Wily package (I had to install an image in VirtualBox.) Unlike the openjdk-6 package from the PPA, it works as expected in the sense that TLSv1.2 is on by default:

nbryant@wily:~$ java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-1ubuntu1~ppa3)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
nbryant@wily:~$ java TLSVersions
java.vendor java.version proto enabledProtocols
Oracle Corporation 1.7.0_79 TLSv1.2 SSLv3,TLSv1,TLSv1.1,TLSv1.2
Oracle Corporation 1.7.0_79 TLSv1.1 SSLv3,TLSv1,TLSv1.1
Oracle Corporation 1.7.0_79 TLSv1 SSLv3,TLSv1
Oracle Corporation 1.7.0_79 TLS SSLv3,TLSv1,TLSv1.1,TLSv1.2
Oracle Corporation 1.7.0_79 SSL SSLv3,TLSv1,TLSv1.1,TLSv1.2

This is a little weird though, SSLv3 is on, even though I have this in java.security:

jdk.tls.disabledAlgorithms=SSLv3, DH keySize < 768

Another small test program. When run on the openjdk-6 PPA test package, it only sends a TLSv1.0 ClientHello. Compare what happens when you change the USE_DEFAULT constant to 'true':

*** ClientHello, TLSv1
RandomCookie: GMT: 1423929043 bytes = { 49, 232, 48, 176, 78, 19, 219, 62, 52, 29, 6, 29, 92, 141, 52, 166, 153, 216, 227, 36, 39, 184, 186, 184, 153, 115, 228, 168 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1}
Extension ec_point_formats, formats: [uncompressed]
***

--- cut here ---
import javax.net.SocketFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocketFactory;
import java.net.Socket;
import java.nio.charset.Charset;

/**
 * TLSSimple
 */
public class TLSSimple
{
  private static final boolean USE_DEFAULT = false;

  public static void main( String[] args )
  {
    System.setProperty( "javax.net.debug", "all" );

    try
    {
      Socket socket = null;
      try
      {
        SocketFactory socketFactory;
        if ( USE_DEFAULT )
        {
          socketFactory = SSLSocketFactory.getDefault();
        }
        else
        {
          SSLContext context = SSLContext.getInstance( "TLS" );
          context.init( null, null, null );
          socketFactory = context.getSocketFactory();
        }
        socket = socketFactory.createSocket( "www.google.com", 443 );
        socket.getOutputStream().write( "GET / HTTP/1.0\n\n".getBytes( Charset.forName( "ISO-8859-1" ) ) );
        byte[] buf = new byte[ 80 ];
        int len = socket.getInputStream().read( buf );
        if ( len > 0 )
        {
          System.out.println( "Success. First " + len + " bytes of response:" );
          System.out.write( buf, 0, len );
        }
        System.out.println( "..." );
      }
      finally
      {
        if ( socket != null )
        {
          socket.close();
        }
      }
    }
    catch ( Exception e )
    {
      System.err.println( e.toString() );
      System.exit( 1 );
    }
  }
}

Nathan, my apologies for the delay.

I have generated new packages for Precise for both OpenJDK 6 and 7. Please note that I have not backported TLS v1.2 support for OpenJDK 6, I only enabled TLS v1.1 by default (see bellow).

I have found and corrected the SSLv3 issue. It was caused when my backport "reverted" a few changes from the "8061210 Issues in TLS" fix. On OpenJDK 8 this and a few other changes were applied after "7093640: Enable client-side TLS 1.2 by default", but on OpenJDK 7 and 6 those changes were applied without "7093640".

I'm not backporting TLS v1.2 to OpenJDK 6 at this time due to 2 reasons:
1. OpenJDK 6 state is worse of then 7, lots of JDK 8 and 7 fixes were backported to it without TLS v1.2 ever been applied, thus there a lot of conflicts to go through and then each of those backports would have to be reviewed (I know because I tried). This spans a lot of classes and requires a very good knowledge of the affected classes and of each fix.
2. The only opinion I got when I asked on jdk6-dev about backporting TLS v1.2 to OpenJDK 6 was against the backport and no one else tipped in, so it OpenJDK 6 devs do not seem to be interested in it at all. [1]

I will keep an eye out to check how this goes, for now TLS v1.1 is still acceptable [2]. Eventually if someone from OpenJDK 6 agrees to help we can try backporting TLS v1.2 there again.

[1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2015-August/003541.html
[2] "... minimum of TLS v1.1, although entities are strongly encouraged to consider TLS v1.2. Note that not all implementations of TLS v1.1 are considered secure – refer to NIST SP 800-52 rev 1 for guidance on secure TLS configurations" https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information_Supplement_v1.pdf

Tiago--thanks, I've just found some time to test this again. We have some servers with TLSv1.0 disabled now, and I've tested your Precise JDK7 package against those--this works, the old package does not connect and the new package connects.

I will follow up with a JDK6 test.

JDK6 is not working as expected. See my test programs above posted in previous comments.

Actual result:

---
$ java -version
java version "1.6.0_36"
OpenJDK Runtime Environment (IcedTea6 1.13.8) (6b36-1.13.8-0ubuntu2~ppa2~snapshot20150911020748)
OpenJDK 64-Bit Server VM (build 23.25-b01, mixed mode)
$ java TLSVersions
java.vendor java.version proto enabledProtocols
Sun Microsystems Inc. 1.6.0_36 TLSv1.2 java.security.NoSuchAlgorithmException: TLSv1.2 SSLContext not available
Sun Microsystems Inc. 1.6.0_36 TLSv1.1 TLSv1,TLSv1.1
Sun Microsystems Inc. 1.6.0_36 TLSv1 TLSv1
Sun Microsystems Inc. 1.6.0_36 TLS TLSv1
Sun Microsystems Inc. 1.6.0_36 SSL TLSv1
---

Expected result:

---
$ java TLSVersions
java.vendor java.version proto enabledProtocols
Sun Microsystems Inc. 1.6.0_36 TLSv1.2 java.security.NoSuchAlgorithmException: TLSv1.2 SSLContext not available
Sun Microsystems Inc. 1.6.0_36 TLSv1.1 TLSv1,TLSv1.1
Sun Microsystems Inc. 1.6.0_36 TLSv1 TLSv1
Sun Microsystems Inc. 1.6.0_36 TLS TLSv1,TLSv1.1
Sun Microsystems Inc. 1.6.0_36 SSL TLSv1
---

A failure to connect result can also be seen if you take TLSSimple.java and edit socketFactory.createSocket( "www.google.com"... to point to some server that has TLSv1.0 entirely disabled. The point is that SSLContext.getInstance( "TLS" ) should return a context that supports a v1.1 hello because SSLContext.getInstance( "TLS" ) is not version-specific and should return a default instance. This is the approach that JDK7 has taken.

I want to amend that comment. The expected result should be-

---
$ java TLSVersions
java.vendor java.version proto enabledProtocols
Sun Microsystems Inc. 1.6.0_36 TLSv1.2 java.security.NoSuchAlgorithmException: TLSv1.2 SSLContext not available
Sun Microsystems Inc. 1.6.0_36 TLSv1.1 TLSv1,TLSv1.1
Sun Microsystems Inc. 1.6.0_36 TLSv1 TLSv1
Sun Microsystems Inc. 1.6.0_36 TLS TLSv1,TLSv1.1
Sun Microsystems Inc. 1.6.0_36 SSL TLSv1,TLSv1.1
---