openjdk team mailing list archive

[Nathan Bryant <nrb@xxxxxxxxxxxxx>]

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.

-- 
You received this bug notification because you are a member of OpenJDK,
which is subscribed to openjdk-7 in Ubuntu.
https://bugs.launchpad.net/bugs/1482924

Title:
  Regressions due to USN-2696-1

Status in openjdk-6 package in Ubuntu:
  New
Status in openjdk-7 package in Ubuntu:
  New

Bug description:
  Due to [CBCATT], some server administrators (including the webservices
  gateway for a major airline reservations provider) choose to disable
  CBC ciphersuites unless the protocol level is TLSv1.1 or later;
  [TLS1.1] introduced an explicit CBC IV to guard against such attacks.
  (See [TLS1.1] section 1.1) On such servers, disabling all CBC
  ciphersuites may leave only RC4 as a trusted cipher.

  JDK7 introduced support for TLSv1.2, but chose not to enable it by
  default, due to a policy of not changing such defaults in minor
  revisions. JDK8 enables TLSv1.2 by default.

  On Ubuntu, due to USN-2696-1, starting with the openjdk-7-jre-7u79-2.5.6-0ubuntu1.12.04.1 package, RC4 is disabled by default but the protocol default remains TLSv1.0. This can leave no remaining trusted ciphers, and
  negotiation can fail.

  Workaround: on OpenJDK7, it is possible to either use
  SSLContext.getInstance("TLSv1.2") or re-enable RC4 via
  SSLSocket.setEnabledCipherSuites(), but neither workaround is viable
  if one doesn't have access to 3rd-party source code.

  References:

     [TLS1.1]   Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.1", RFC 4346, April 2006.
                https://www.ietf.org/rfc/rfc4346.txt

     [CBCATT]   Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
                Problems and Countermeasures",
                http://www.openssl.org/~bodo/tls-cbc.txt.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1482924/+subscriptions