Java 1.6 SSL degraded to 768 bit DHE_RSA/SHA

I have encountered a problem in Java 1.6 with Java SSL servers and Diffie-Hellman key agreement, as compared to the same SSL servers in Java 1.5.

Opera issues warnings if SSL connections do not meet its security standards. Java SSL servers in Java 1.5 use the following encryption protocol (as reported in Opera):

TLS v1.0 128 bit AES (1024 bit DHE_RSA/SHA)

Whereas Java SSL servers in Java 1.6 use the following:

TLS v1.0 128 bit AES (768 bit DHE_RSA/SHA)

Opera considers (and I believe there is evidence to back this up) DHE of less than 900 bits to be insecure.

This can be reproduced using Tomcat with its built-in SSL support and running it with Java 1.5 and then 1.6.

Is there something that's missing in the configuration or can anyone shed any light on what is happening?

Kind regards,

Karl

[860 byte] By [karlvra] at [2007-11-27 4:22:11]
# 1
Have you installed the unlimited-strength jurisdiction files for the 1.6 installation?
ejpa at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 2

I didn't have the unlimited-strength jurisdiction files installed for either the 1.5 or 1.6 installation. I have installed the unlimited-strength jurisdiction files for 1.6 and the encryption protocol has changed from:

TLS v1.0 128 bit AES (768 bit DHE_RSA/SHA)

to

TLS v1.0 256 bit AES (768 bit DHE_RSA/SHA)

So it has increased the AES strength but the DHE_RSA strength remains at 768 bit.

karlvra at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 3

Karlvr,

I have been trying to solve a problem related to a move from 1.5 to 1.6 and you provide interesting information.

If you are curious, here is the issue i've found:

http://forum.java.sun.com/thread.jspa?threadID=5167489&tstart=0

In my case an exception is being generated here:

Caused by: java.lang.NullPointerException

at com.sun.deploy.security.X509ExtendedDeployTrustManager.isSupportedAlgorithm(Unknown Source)

at com.sun.deploy.security.X509ExtendedDeployTrustManager.checkServerTrusted(Unknown Source)

at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)

at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)

at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)

at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)

... 13 more

AlfredTheGreya at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 4

Yes I saw your post. I haven't encountered that problem yet in 1.6 and my application, Charles (http://www.xk72.com/charles/) uses a lot of SSL connectivity. I'll be keeping an eye out for it though.

To add more data to this topic I have run a test with -Djavax.net.debug=ALL on both 1.5 and 1.6. Comparing side to side these are the interesting things I noticed:

The cipher suites are the same (this is both without the unlimited strength): TLS_DHE_RSA_WITH_AES_128_CBC_SHA

When we get to the Diffie-Hellman ServerKeyExchange there is a distinct difference. Here is the 1.5 data:

DH Modulus: { 244, 136, 253, 88, 78, 73, 219, 205, 32, 180, 157, 228, 145, 7, 54, 107, 51, 108, 56, 13, 69, 29, 15, 124, 136, 179, 28, 124, 91, 45, 142, 246, 243, 201, 35, 192, 67, 240, 165, 91, 24, 141, 142, 187, 85, 140, 184, 93, 56, 211, 52, 253, 124, 23, 87, 67, 163, 29, 24, 108, 222, 51, 33, 44, 181, 42, 255, 60, 225, 177, 41, 64, 24, 17, 141, 124, 132, 167, 10, 114, 214, 134, 196, 3, 25, 200, 7, 41, 122, 202, 149, 12, 217, 150, 159, 171, 208, 10, 80, 155, 2, 70, 211, 8, 61, 102, 164, 93, 65, 159, 156, 124, 189, 137, 75, 34, 25, 38, 186, 171, 162, 94, 195, 85, 233, 47, 120, 199 }

DH Base: { 2 }

Server DH Public Key: { 166, 113, 134, 60, 151, 15, 198, 46, 3, 2, 155, 221, 116, 155, 113, 142, 11, 10, 251, 84, 70, 231, 34, 98, 155, 42, 173, 14, 50, 1, 210, 120, 186, 26, 86, 189, 213, 109, 86, 126, 212, 52, 149, 129, 97, 186, 76, 54, 216, 212, 161, 75, 215, 254, 18, 120, 138, 103, 239, 169, 111, 4, 185, 14, 231, 117, 85, 191, 11, 95, 195, 7, 17, 33, 186, 156, 69, 218, 240, 30, 238, 189, 108, 59, 61, 253, 6, 8, 88, 179, 42, 199, 217, 215, 227, 206, 139, 122, 79, 55, 23, 175, 246, 212, 101, 4, 198, 30, 35, 203, 194, 181, 66, 44, 195, 95, 108, 251, 124, 27, 155, 45, 210, 62, 171, 33, 152, 188 }

Signed with a DSA or RSA public key

*** ServerHelloDone

In comparison to the 1.6 data:

DH Modulus: { 233, 230, 66, 89, 157, 53, 95, 55, 201, 127, 253, 53, 103, 18, 11, 142, 37, 201, 205, 67, 233, 39, 179, 169, 103, 15, 190, 197, 216, 144, 20, 25, 34, 210, 195, 179, 173, 36, 128, 9, 55, 153, 134, 157, 30, 132, 106, 171, 73, 250, 176, 173, 38, 210, 206, 106, 34, 33, 157, 71, 11, 206, 125, 119, 125, 74, 33, 251, 233, 194, 112, 181, 127, 96, 112, 2, 243, 206, 248, 57, 54, 148, 207, 69, 238, 54, 136, 193, 26, 140, 86, 171, 18, 122, 61, 175 }

DH Base: { 48, 71, 10, 213, 160, 5, 251, 20, 206, 45, 157, 205, 135, 227, 139, 199, 209, 177, 197, 250, 203, 174, 203, 233, 95, 25, 10, 167, 163, 29, 35, 196, 219, 188, 190, 6, 23, 69, 68, 64, 26, 91, 44, 2, 9, 101, 216, 194, 189, 33, 113, 211, 102, 132, 69, 119, 31, 116, 186, 8, 77, 32, 41, 216, 60, 28, 21, 133, 71, 243, 169, 241, 162, 113, 91, 226, 61, 81, 174, 77, 62, 90, 31, 106, 112, 100, 243, 22, 147, 58, 52, 109, 63, 82, 146, 82 }

Server DH Public Key: { 165, 203, 243, 184, 118, 34, 108, 81, 74, 214, 231, 29, 35, 156, 42, 155, 53, 192, 107, 140, 25, 219, 111, 242, 188, 101, 218, 39, 83, 97, 141, 14, 171, 169, 69, 152, 203, 196, 58, 66, 87, 53, 126, 235, 187, 72, 115, 94, 132, 107, 93, 69, 117, 235, 17, 121, 30, 53, 191, 177, 78, 146, 21, 0, 184, 209, 80, 71, 173, 63, 57, 121, 212, 123, 41, 97, 185, 150, 50, 12, 178, 18, 206, 143, 38, 113, 218, 208, 246, 237, 45, 167, 162, 136, 79, 177 }

Signed with a DSA or RSA public key

*** ServerHelloDone

The biggest difference I can see is the in 1.5 the DH Modulus and Server DH Public Key are somewhat longer than in 1.6, while the DH Base is a single byte in 1.5 and many bytes in 1.6. Scientific.

karlvra at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 5
karlvr,Can you describe how your application communicates with the server?Are you using applets with Plain Old Java Objects, XML, RMI, etc.?Thanks.-Dennis
AlfredTheGreya at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 6

Hi Dennis,

Plain old HTTP(S). Charles is an HTTP proxy for debugging web applications, so its SSL function is to act as man-in-the-middle talking to the client and the server. So there is nothing higher level than reading and writing from the secure streams; the most basic use of the Java SSL sockets.

cheers,

Karl

karlvra at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 7
I just found the same problem today. Will Opera still complain if I install the aforementioned files? I haven't moved my production box to JDK 1.6 yet, what are the security implications of 768 bit DHE_RSA/SHA vs. 1024 bit? Is there a workaround?
jleecha at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 8
Yes, I believe that Opera will still complain as the key exchange will continue to use 768 bit which it believes is insecure.I guess if Opera were a bigger browser then this might get more attention, as it compromises every Java SSL server.
karlvra at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...
# 9

I have confirmed that it still complains.

This situation sucks out loud.

I am going to poke around in the Java source code and see if there are any magic System properties or other configurable parameters to change the key length.

In the JSSE Reference Guide (http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Features),

it doesn't even list 768 as an option for the key length, just 1025 and 512.

If there aren't, this seems like a JDK bug to me. Unfortunately my experience with JDK bugs is that they sometimes, eventually, get fixed. Eventually means like 5 years later.

It would probably be worth it to raise this issue as a bug with every servlet container - Tomcat, Jetty, Glassfish, etc. etc.

At a minimum there needs to be documentation in them, saying 'don't use jdk1.6', or 'configure jdk1.6 in the following way else it won't be secure'.

Also I am going to look into alternative crypto providers, e.g. BouncyCastle, and see if any of them work correctly.

jleecha at 2007-7-12 9:29:26 > top of Java-index,Security,Java Secure Socket Extension (JSSE)...