← Back to team overview

openjdk team mailing list archive

[Bug 1482924] Re: Regressions due to USN-2696-1

 

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 );
    }
  }
}

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


References