Name: bsC130419 Date: 08/22/2001


java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)


When cipher suite SSL_DH_anon_WITH_DES_CBC_SHA and cipher suite
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA are both enabled, the order of preference
during SSL negotiation has cipher suite SSL_DH_anon_WITH_DES_CBC_SHA (the
weaker of the two) listed first. If my client connects to a server that
supports only DES and 3DES and if both are enabled on the server, then the
connection occurs at DES instead of the stronger 3DES.

I see no way to set the order of preference for the enabled cipher suites. The
order of the list that is passed to SSLSocket.setEnabledCipherSuites() does not
have any affect on the order of preference sent during SSL negotiation. It
appears to me that the JSSE always tries to set the order of preference from
strongest to weakest during SSL negotiation. I believe there is a bug which is
causing SSL_DH_anon_WITH_DES_CBC_SHA to be ordered before
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA.

Here is a sample of the code I am using, and a debug trace output from the JSSE
showing the list of cipher suites sent during an SSL negotiation using this
code:

try
{
    Security.addProvider( new com.sun.net.ssl.internal.ssl.Provider() );
    SSLSocketFactory sslsf = (SSLSocketFactory)SSLSocketFactory.getDefault();
    SSLSocket ssls = (SSLSocket)sslsf.createSocket( 192.168.0.1, 8192 );
    
    String[] aszEnabledCipherSuites = new String[]
    {
      "SSL_DH_anon_WITH_RC4_128_MD5"
      "SSL_DH_anon_WITH_3DES_EDE_CBC_SHA",
      "SSL_DH_anon_WITH_DES_CBC_SHA"
   };
   
   ssls.setEnabledCipherSuites( aszEnabledCipherSuites );
   
   // Next data would be sent over the socket which
   // would cause SSL negotiation to occur

}
catch( Exception ex )
{}

Here is the JSSE trace debug output for the beginning of the SSL negotiation
with the cipher suites listed in the sample code above enabled. Note that in
the Cipher Suites: debug trace, the value 24 = SSL_DH_anon_WITH_RC4_128_MD5,
the value 26 = SSL_DH_anon_WITH_DES_CBC_SHA, and the value 27 =
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA. The server that I connected to only has DES
and 3DES enabled.

You will see that the value 26 comes in the list before 27, and as a result,
the server that I connected to came back with 26 (DES) as the agreed upon
cipher suite.

%% No cached client session
*** ClientHello, v3.1
RandomCookie: GMT: 981733029 bytes = { 172, 90, 90, 146, 175, 184, 215, 86, 200
, 181, 19, 156, 218, 101, 55, 179, 4, 202, 113, 244, 20, 160, 111, 42, 84, 99, 1
87, 217 }
Session ID: {}
Cipher Suites: { 0, 24, 0, 26, 0, 27 }
Compression Methods: { 0 }
***
[write] MD5 and SHA1 hashes: len = 49
0000: 01 00 00 2D 03 01 3B 84 0F A5 AC 5A 5A 92 AF B8 ...-..;....ZZ...
0010: D7 56 C8 B5 13 9C DA 65 37 B3 04 CA 71 F4 14 A0 .V.....e7...q...
0020: 6F 2A 54 63 BB D9 00 00 06 00 18 00 1A 00 1B 01 o*Tc............
0030: 00 .
Thread-90, WRITE: SSL v3.1 Handshake, length = 49
[write] MD5 and SHA1 hashes: len = 50
0000: 01 03 01 00 09 00 00 00 20 00 00 18 00 00 1A 00 ........ .......
0010: 00 1B 3B 84 0F A5 AC 5A 5A 92 AF B8 D7 56 C8 B5 ..;....ZZ....V..
0020: 13 9C DA 65 37 B3 04 CA 71 F4 14 A0 6F 2A 54 63 ...e7...q...o*Tc
0030: BB D9 ..
Thread-90, WRITE: SSL v2, contentType = 22, translated length = 16337
Thread-90, READ: SSL v3.1 Handshake, length = 74
*** ServerHello, v3.1
RandomCookie: GMT: -16843009 bytes = { 34, 72, 27, 49, 101, 58, 255, 161, 4, 24
, 31, 169, 144, 131, 19, 223, 34, 225, 238, 99, 151, 235, 219, 18, 240, 17, 18,
193 }
Session ID: {16, 200, 254, 215, 25, 41, 218, 32, 28, 175, 88, 95, 9, 82, 225, 6
8, 2, 35, 95, 133, 231, 219, 69, 32, 161, 25, 212, 205, 185, 94, 222, 157}
Cipher Suite: { 0, 26 }
Compression Method: 0
(Review ID: 130486)
======================================================================