openjdk team mailing list archive

[Nathan Bryant <nrb@xxxxxxxxxxxxx>]

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 t...@xxxxxxxxx
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.

** Bug watch added: code.google.com/p/chromium/issues #375342
   http://code.google.com/p/chromium/issues/detail?id=375342

-- 
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