openjdk team mailing list archive
-
openjdk team
-
Mailing list archive
-
Message #11098
[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