JDK-4414143 : SSL problem when using JNDI
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 1.0.2,1.3.0_01
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux,windows_2000
  • CPU: x86
  • Submitted: 2001-02-10
  • Updated: 2001-08-29
  • Resolved: 2001-08-29
Related Reports
Relates :  
Relates :  
Description
 Spec, length = 1
ExecuteThread-39, READ:  SSL v3.1 Handshake, length = 32
Plaintext after DECRYPTION:  len = 32
0000: 14 00 00 0C 79 E4 FA 57   99 0F DB 06 B7 9C 41 74  ....y..W......At
0010: D0 48 FD ED A4 E9 94 7B   97 41 C3 24 05 95 EE C8  .H.......A.$....
*** Finished, v3.1
verify_data:  { 121, 228, 250, 87, 153, 15, 219, 6, 183, 156, 65, 116 }
***
[read] MD5 and SHA1 hashes:  len = 16
0000: 14 00 00 0C 79 E4 FA 57   99 0F DB 06 B7 9C 41 74  ....y..W......At
ExecuteThread-39, WRITE:  SSL v3.1 Change Cipher Spec, length = 1
*** Finished, v3.1
verify_data:  { 181, 35, 80, 217, 254, 133, 154, 105, 66, 23, 155, 124 }
***
[write] MD5 and SHA1 hashes:  len = 16
0000: 14 00 00 0C B5 23 50 D9   FE 85 9A 69 42 17 9B 7C  .....#P....iB...
Plaintext before ENCRYPTION:  len = 32
0000: 14 00 00 0C B5 23 50 D9   FE 85 9A 69 42 17 9B 7C  .....#P....iB...
0010: CF 88 2F 2C 36 BE 16 BD   D1 26 33 07 E6 51 1E 51  ../,6....&3..Q.Q
ExecuteThread-39, WRITE:  SSL v3.1 Handshake, length = 32
%% Cached client session: [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5]
Plaintext before ENCRYPTION:  len = 111
0000: 30 5D 02 01 01 60 3B 02   01 03 04 2D 43 4E 3D 4A  0]...`;....-CN=J
0010: 69 61 6E 6C 69 61 6E 67   20 5A 68 61 6F 2C 43 4E  ianliang Zhao,CN
0020: 3D 55 73 65 72 73 2C 44   43 3D 65 6E 67 2D 74 65  =Users,DC=eng-te
0030: 73 74 2C 44 43 3D 63 6F   6D 80 07 77 65 6C 63 6F  st,DC=com..welco
0040: 6D 65 A0 1B 30 19 04 17   32 2E 31 36 2E 38 34 30  me..0...2.16.840
0050: 2E 31 2E 31 31 33 37 33   30 2E 33 2E 34 2E 32 85  .1.113730.3.4.2.
0060: FC A0 B3 EB 49 98 4C C4   2F 72 7E B5 0A 6A B1     ....I.L./r...j.
ExecuteThread-39, WRITE:  SSL v3.1 Application Data, length = 111
Thread-5, READ:  SSL v3.1 Handshake, length = 20
Plaintext after DECRYPTION:  len = 20
0000: 00 00 00 00 5F 3B AE B8   F7 35 AF C1 BE 2F 0E C3  ...._;...5.../..
0010: 58 ED AE B4                                        X...
*** HelloRequest (empty)
%% Client cached [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5]
%% Try resuming [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5] from port 2156
*** ClientHello, v3.1
RandomCookie:  GMT: 972612956 bytes = { 151, 130, 244, 196, 75, 206, 142, 249, 5
3, 231, 223, 176, 60, 195, 238, 113, 87, 74, 76, 201, 49, 111, 102, 226, 199, 11
4, 249, 226 }
Session ID:  {0, 0, 0, 0, 61, 83, 245, 147, 3, 5, 166, 41, 113, 48, 82, 108, 228
, 184, 175, 29, 8, 91, 111, 22, 50, 123, 58, 78, 52, 2, 58, 195}
Cipher Suites:  { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 }
Compression Methods:  { 0 }
***
[write] MD5 and SHA1 hashes:  len = 91
0000: 01 00 00 57 03 01 3A F9   E5 5C 97 82 F4 C4 4B CE  ...W..:..\....K.
0010: 8E F9 35 E7 DF B0 3C C3   EE 71 57 4A 4C C9 31 6F  ..5...<..qWJL.1o
0020: 66 E2 C7 72 F9 E2 20 00   00 00 00 3D 53 F5 93 03  f..r.. ....=S...
0030: 05 A6 29 71 30 52 6C E4   B8 AF 1D 08 5B 6F 16 32  ..)q0Rl.....[o.2
0040: 7B 3A 4E 34 02 3A C3 00   10 00 05 00 04 00 09 00  .:N4.:..........
0050: 0A 00 12 00 13 00 03 00   11 01 00                 ...........
Plaintext before ENCRYPTION:  len = 107
0000: 01 00 00 57 03 01 3A F9   E5 5C 97 82 F4 C4 4B CE  ...W..:..\....K.
0010: 8E F9 35 E7 DF B0 3C C3   EE 71 57 4A 4C C9 31 6F  ..5...<..qWJL.1o
0020: 66 E2 C7 72 F9 E2 20 00   00 00 00 3D 53 F5 93 03  f..r.. ....=S...
0030: 05 A6 29 71 30 52 6C E4   B8 AF 1D 08 5B 6F 16 32  ..)q0Rl.....[o.2
0040: 7B 3A 4E 34 02 3A C3 00   10 00 05 00 04 00 09 00  .:N4.:..........
0050: 0A 00 12 00 13 00 03 00   11 01 00 4A 4B C0 68 35  ...........JK.h5
0060: 3B 3D 48 B5 DA B7 1C EE   22 3A DC                 ;=H.....":.
Thread-5, WRITE:  SSL v3.1 Handshake, length = 107


Exception:
javax.naming.ServiceUnavailableException: engtestdc1:636
	at com.sun.jndi.ldap.Connection.readReply(Connection.java:222)
	at com.sun.jndi.ldap.Connection.readReply(Connection.java:244)
	at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:284)
	at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:140)
	at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2336)
	at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2289)
	at com.sun.jndi.ldap.LdapCtx.reconnect(LdapCtx.java:2272)
(Review ID: 124123)
======================================================================


Name: krC82822			Date: 02/10/2001


java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)

I've spent some time trying to figure a strange JNDI problem out, and after
turning on a lot of debugging, it appears to be some kind of SSL problem.
Notable is that if I use stunnel to handle the SSL side of things, and don't
enable SSL in my java application, everything works just fine.

I'm using the release version of JDK 1.3 on linux, with JSSE 1.0.2. The target
LDAP server is Windows 2000 SP1, with an Enterprise CA installed.

I have test-case code that simply creates an InitialDirContext via LDAP over
SSL, then closes it (this code is at the end of the message). I repeat this
process over and over, and somewhere between the 2nd and 10th attempt, I end up
with a ServiceUnavailableException. But strange behavior reported by enabling
javax.net.debug=all seems to indicate an SSL issue.

Without posting the whole SSL debug output, here is the most detailed info I
can provide: when it WORKS, the JNDI authentication information (the initiation
of the directory context) is passed through SSL causing this message:

main, WRITE: SSL v3.1 Application Data, length = 119
Thread-1, READ: SSL v3.1 Application Data, length = 38

and everything proceeds normally.

When it does NOT work, the above message looks like this:

main, WRITE: SSL v3.1 Application Data, length = 119
Thread-3, READ: SSL v3.1 Handshake, length = 20

rather than proceeding as things do on the successful connections, after
reading this info, a message that only appears when there is a problem pops up:

*** HelloRequest (empty)

then the process of resuming a cached SSL session starts over yet again, it
ends up writing out a small amount of info and the connection is gone. The LDAP
server side logs an error stating that the client disconnected before the
server could reply.

Thanks so much.

Code:

import java.net.*;
import java.io.*;
import java.util.*;
import javax.naming.*;
import javax.naming.directory.*;
import javax.naming.ldap.*;
import java.security.Security;
import javax.security.cert.*;

public class ldapTestpost {

    private static Hashtable env;
    private static String binddn = "DN of principal here";

    public static void main(String[] args) throws IOException {
        boolean listening = true;

        env = new Hashtable();
        env.put(Context.SECURITY_AUTHENTICATION, "simple");
        env.put(Context.SECURITY_PRINCIPAL, binddn);
        env.put(Context.SECURITY_CREDENTIALS, "password here");
        env.put(Context.SECURITY_PROTOCOL, "ssl");
        env.put
(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
        env.put
(Context.PROVIDER_URL,"ldap://ip.address.of.win2000.ldap.server:636");
//      env.put("com.sun.jndi.ldap.trace.ber", System.err);

/*
//tried this but it doesn't seem to do anything:
        Properties p = new Properties(System.getProperties());
        p.setProperty("javax.net.ssl.sessionCacheSize", "0");
*/
        int num = 0;

        while (listening) {
            openClose();
            num++;
            System.out.println("num: " + num);
        }

    }

    private static void openClose() {

        try {
          DirContext ctx = new InitialLdapContext(env, null);
          if (ctx != null) {
                ctx.close();
                ctx = null;
          }
        } catch (javax.naming.NamingException e) { e.printStackTrace(); }

        return;
    }

}
(Review ID: 112696) 
======================================================================



Name: krC82822			Date: 08/07/2001


java version "1.2.2"
Classic VM (build JDK-1.2.2_006, native threads, symcjit)

I tried to connect to Active Directory Server installed on Win 2000 server with
SSL enabled. The first time I created an InitialLdapContext and it succeeded.
 env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
 env.put(Context.PROVIDER_URL, "ldap://host:636"));
 env.put(Context.SECURITY_PROTOCOL, "ssl");
 env.put(Context.SECURITY_AUTHENTICATION, "simple");
 env.put(Context.SECURITY_PRINCIPAL, "managerdn");
 env.put(Context.SECURITY_CREDENTIALS, "password");
 dirContext = new InitialLdapContext(env, null);

The second time I created new LdapContext intance by using the first instance,
 ctrls=dirContext.getConnectControls();
 ctx=(LdapContext)dirContext.newInstance(ctrls);
 try {
     ctx.reconnect(ctrls);
 }catch(javax.naming.NamingException ce){
     ctx.close();
     ctx.reconnect(ctrls);
 }
I got the ServiceUnavailableException. Both the SSL trace information and
exception stack trace are pasted below.

The problem only happens to Active Directory Server. It works fine with iPlanet
and Exchange Server.

If I use the IAIK JSSE implementation, it works fine with all of them,
including Active Directory server.

Successful one:
StartupThread, WRITE:  SSL v3.1 Application Data, length = 111
Thread-2, READ:  SSL v3.1 Application Data, length = 38
Plaintext after DECRYPTION:  len = 38
0000: 30 84 00 00 00 10 02 01   01 61 84 00 00 00 07 0A  0........a......
0010: 01 00 04 00 04 00 83 29   9B 59 DB EF 22 FC 7F 7B  .......).Y.."...
0020: 98 00 52 28 34 FB                                  ..R(4.

Failed one:
%% Client cached [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5]
%% Try resuming [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5] from port 2154
*** ClientHello, v3.1
RandomCookie:  GMT: 972612940 bytes = { 230, 160, 95, 146, 247, 30, 168, 250, 96
, 117, 156, 112, 80, 100, 185, 68, 151, 225, 90, 223, 22, 187, 66, 92, 39, 120,
132, 112 }
Session ID:  {0, 0, 0, 0, 61, 83, 245, 147, 3, 5, 166, 41, 113, 48, 82, 108, 228
, 184, 175, 29, 8, 91, 111, 22, 50, 123, 58, 78, 52, 2, 58, 195}
Cipher Suites:  { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 }
Compression Methods:  { 0 }
***
[write] MD5 and SHA1 hashes:  len = 91
0000: 01 00 00 57 03 01 3A F9   E5 4C E6 A0 5F 92 F7 1E  ...W..:..L.._...
0010: A8 FA 60 75 9C 70 50 64   B9 44 97 E1 5A DF 16 BB  ..`u.pPd.D..Z...
0020: 42 5C 27 78 84 70 20 00   00 00 00 3D 53 F5 93 03  B\'x.p ....=S...
0030: 05 A6 29 71 30 52 6C E4   B8 AF 1D 08 5B 6F 16 32  ..)q0Rl.....[o.2
0040: 7B 3A 4E 34 02 3A C3 00   10 00 05 00 04 00 09 00  .:N4.:..........
0050: 0A 00 12 00 13 00 03 00   11 01 00                 ...........
ExecuteThread-39, WRITE:  SSL v3.1 Handshake, length = 91
ExecuteThread-39, READ:  SSL v3.1 Handshake, length = 74
*** ServerHello, v3.1
RandomCookie:  GMT: -1761685215 bytes = { 1, 8, 167, 71, 194, 136, 13, 67, 141,
155, 6, 52, 87, 122, 185, 203, 223, 192, 177, 117, 59, 26, 174, 158, 84, 135, 22
4, 39 }
Session ID:  {0, 0, 0, 0, 61, 83, 245, 147, 3, 5, 166, 41, 113, 48, 82, 108, 228
, 184, 175, 29, 8, 91, 111, 22, 50, 123, 58, 78, 52, 2, 58, 195}
Cipher Suite:  { 0, 3 }
Compression Method: 0
***
%% Server resumed [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5]
CONNECTION KEYGEN:
Client Nonce:
0000: 3A F9 E5 4C E6 A0 5F 92   F7 1E A8 FA 60 75 9C 70  :..L.._.....`u.p
0010: 50 64 B9 44 97 E1 5A DF   16 BB 42 5C 27 78 84 70  Pd.D..Z...B\'x.p
Server Nonce:
0000: 97 FF D1 21 01 08 A7 47   C2 88 0D 43 8D 9B 06 34  ...!...G...C...4
0010: 57 7A B9 CB DF C0 B1 75   3B 1A AE 9E 54 87 E0 27  Wz.....u;...T..'
Master Secret:
0000: D9 84 BA ED 50 C3 9C 22   C3 5E FB B4 42 78 CA FE  ....P..".^..Bx..
0010: 79 C2 1B 86 1E E9 71 41   42 81 34 ED 62 81 F5 44  y.....qAB.4.b..D
0020: 7C D6 60 FB 45 30 E7 9C   78 00 75 11 AB 17 44 C9  ..`.E0..x.u...D.
Client MAC write Secret:
0000: E3 7C C4 A7 6F AE 2B 08   E3 3C 44 07 C3 51 1C 7E  ....o.+..<D..Q..
Server MAC write Secret:
0000: BD 91 5E AA 24 69 B1 53   16 D5 B3 49 0F 74 06 6B  ..^.$i.S...I.t.k
Client write key:
0000: 06 2B DF 1F 3F 24 B9 D2   36 89 CF C5 2F C7 9C 98  .+..?$..6.../...
Server write key:
0000: BB 5F B3 D8 47 A3 8A C8   16 51 6B B0 28 0D B4 03  ._..G....Qk.(...
... no IV for cipher
[read] MD5 and SHA1 hashes:  len = 74
0000: 02 00 00 46 03 01 97 FF   D1 21 01 08 A7 47 C2 88  ...F.....!...G..
0010: 0D 43 8D 9B 06 34 57 7A   B9 CB DF C0 B1 75 3B 1A  .C...4Wz.....u;.
0020: AE 9E 54 87 E0 27 20 00   00 00 00 3D 53 F5 93 03  ..T..' ....=S...
0030: 05 A6 29 71 30 52 6C E4   B8 AF 1D 08 5B 6F 16 32  ..)q0Rl.....[o.2
0040: 7B 3A 4E 34 02 3A C3 00   03 00                    .:N4.:....
ExecuteThread-39, READ:  SSL v3.1 Change Cipher Spec, length = 1
ExecuteThread-39, READ:  SSL v3.1 Handshake, length = 32
Plaintext after DECRYPTION:  len = 32
0000: 14 00 00 0C 27 DC 7B B9   71 A3 B5 71 23 0E 89 77  ....'...q..q#..w
0010: F7 4A 30 FD CA BC 1C 88   06 89 2A 02 9B B9 2C 1E  .J0.......*...,.
*** Finished, v3.1
verify_data:  { 39, 220, 123, 185, 113, 163, 181, 113, 35, 14, 137, 119 }
***
[read] MD5 and SHA1 hashes:  len = 16
0000: 14 00 00 0C 27 DC 7B B9   71 A3 B5 71 23 0E 89 77  ....'...q..q#..w
ExecuteThread-39, WRITE:  SSL v3.1 Change Cipher Spec, length = 1
*** Finished, v3.1
verify_data:  { 89, 48, 118, 178, 7, 155, 250, 142, 100, 110, 125, 232 }
***
[write] MD5 and SHA1 hashes:  len = 16
0000: 14 00 00 0C 59 30 76 B2   07 9B FA 8E 64 6E 7D E8  ....Y0v.....dn..
Plaintext before ENCRYPTION:  len = 32
0000: 14 00 00 0C 59 30 76 B2   07 9B FA 8E 64 6E 7D E8  ....Y0v.....dn..
0010: DC 8B 3F A1 CF AD 35 15   C2 48 32 41 62 61 52 4A  ..?...5..H2AbaRJ
ExecuteThread-39, WRITE:  SSL v3.1 Handshake, length = 32
%% Cached client session: [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5]
Plaintext before ENCRYPTION:  len = 111
0000: 30 5D 02 01 01 60 3B 02   01 03 04 2D 43 4E 3D 4A  0]...`;....-CN=J
0010: 69 61 6E 6C 69 61 6E 67   20 5A 68 61 6F 2C 43 4E  ianliang Zhao,CN
0020: 3D 55 73 65 72 73 2C 44   43 3D 65 6E 67 2D 74 65  =Users,DC=eng-te
0030: 73 74 2C 44 43 3D 63 6F   6D 80 07 77 65 6C 63 6F  st,DC=com..welco
0040: 6D 65 A0 1B 30 19 04 17   32 2E 31 36 2E 38 34 30  me..0...2.16.840
0050: 2E 31 2E 31 31 33 37 33   30 2E 33 2E 34 2E 32 C6  .1.113730.3.4.2.
0060: 71 BF 4E BD EB 8D C7 4A   43 08 93 96 85 8F FE     q.N....JC......
ExecuteThread-39, WRITE:  SSL v3.1 Application Data, length = 111
Thread-4, READ:  SSL v3.1 Handshake, length = 20
Plaintext after DECRYPTION:  len = 20
0000: 00 00 00 00 EC 17 A9 95   41 41 EF 47 F2 DA D0 B1  ........AA.G....
0010: 2B F0 B6 4D                                        +..M
*** HelloRequest (empty)
%% Client cached [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5]
%% Try resuming [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5] from port 2154
*** ClientHello, v3.1
RandomCookie:  GMT: 972612940 bytes = { 49, 173, 179, 110, 255, 2, 236, 84, 77,
102, 149, 237, 85, 190, 10, 44, 138, 19, 124, 18, 168, 71, 172, 129, 239, 48, 41
, 252 }
Session ID:  {0, 0, 0, 0, 61, 83, 245, 147, 3, 5, 166, 41, 113, 48, 82, 108, 228
, 184, 175, 29, 8, 91, 111, 22, 50, 123, 58, 78, 52, 2, 58, 195}
Cipher Suites:  { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 }
Compression Methods:  { 0 }
***
[write] MD5 and SHA1 hashes:  len = 91
0000: 01 00 00 57 03 01 3A F9   E5 4C 31 AD B3 6E FF 02  ...W..:..L1..n..
0010: EC 54 4D 66 95 ED 55 BE   0A 2C 8A 13 7C 12 A8 47  .TMf..U..,.....G
0020: AC 81 EF 30 29 FC 20 00   00 00 00 3D 53 F5 93 03  ...0). ....=S...
0030: 05 A6 29 71 30 52 6C E4   B8 AF 1D 08 5B 6F 16 32  ..)q0Rl.....[o.2
0040: 7B 3A 4E 34 02 3A C3 00   10 00 05 00 04 00 09 00  .:N4.:..........
0050: 0A 00 12 00 13 00 03 00   11 01 00                 ...........
Plaintext before ENCRYPTION:  len = 107
0000: 01 00 00 57 03 01 3A F9   E5 4C 31 AD B3 6E FF 02  ...W..:..L1..n..
0010: EC 54 4D 66 95 ED 55 BE   0A 2C 8A 13 7C 12 A8 47  .TMf..U..,.....G
0020: AC 81 EF 30 29 FC 20 00   00 00 00 3D 53 F5 93 03  ...0). ....=S...
0030: 05 A6 29 71 30 52 6C E4   B8 AF 1D 08 5B 6F 16 32  ..)q0Rl.....[o.2
0040: 7B 3A 4E 34 02 3A C3 00   10 00 05 00 04 00 09 00  .:N4.:..........
0050: 0A 00 12 00 13 00 03 00   11 01 00 A3 DD 41 DB D4  .............A..
0060: 98 5D 16 79 7C 94 E2 04   96 13 B3                 .].y.......
Thread-4, WRITE:  SSL v3.1 Handshake, length = 107
%% Client cached [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5]
%% Try resuming [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5] from port 2156
*** ClientHello, v3.1
RandomCookie:  GMT: 972612956 bytes = { 246, 35, 88, 232, 78, 120, 9, 14, 58, 21
3, 217, 173, 193, 212, 193, 42, 241, 129, 153, 191, 198, 85, 55, 96, 20, 116, 2,
 102 }
Session ID:  {0, 0, 0, 0, 61, 83, 245, 147, 3, 5, 166, 41, 113, 48, 82, 108, 228
, 184, 175, 29, 8, 91, 111, 22, 50, 123, 58, 78, 52, 2, 58, 195}
Cipher Suites:  { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 }
Compression Methods:  { 0 }
***
[write] MD5 and SHA1 hashes:  len = 91
0000: 01 00 00 57 03 01 3A F9   E5 5C F6 23 58 E8 4E 78  ...W..:..\.#X.Nx
0010: 09 0E 3A D5 D9 AD C1 D4   C1 2A F1 81 99 BF C6 55  ..:......*.....U
0020: 37 60 14 74 02 66 20 00   00 00 00 3D 53 F5 93 03  7`.t.f ....=S...
0030: 05 A6 29 71 30 52 6C E4   B8 AF 1D 08 5B 6F 16 32  ..)q0Rl.....[o.2
0040: 7B 3A 4E 34 02 3A C3 00   10 00 05 00 04 00 09 00  .:N4.:..........
0050: 0A 00 12 00 13 00 03 00   11 01 00                 ...........
ExecuteThread-39, WRITE:  SSL v3.1 Handshake, length = 91
ExecuteThread-39, READ:  SSL v3.1 Handshake, length = 74
*** ServerHello, v3.1
RandomCookie:  GMT: 1519378313 bytes = { 62, 44, 48, 99, 244, 169, 211, 16, 159,
 1, 233, 36, 204, 104, 170, 190, 32, 165, 90, 27, 89, 0, 118, 153, 138, 163, 22,
 144 }
Session ID:  {0, 0, 0, 0, 61, 83, 245, 147, 3, 5, 166, 41, 113, 48, 82, 108, 228
, 184, 175, 29, 8, 91, 111, 22, 50, 123, 58, 78, 52, 2, 58, 195}
Cipher Suite:  { 0, 3 }
Compression Method: 0
***
%% Server resumed [Session-1, SSL_RSA_EXPORT_WITH_RC4_40_MD5]
CONNECTION KEYGEN:
Client Nonce:
0000: 3A F9 E5 5C F6 23 58 E8   4E 78 09 0E 3A D5 D9 AD  :..\.#X.Nx..:...
0010: C1 D4 C1 2A F1 81 99 BF   C6 55 37 60 14 74 02 66  ...*.....U7`.t.f
Server Nonce:
0000: 5B 90 E0 89 3E 2C 30 63   F4 A9 D3 10 9F 01 E9 24  [...>,0c.......$
0010: CC 68 AA BE 20 A5 5A 1B   59 00 76 99 8A A3 16 90  .h.. .Z.Y.v.....
Master Secret:
0000: D9 84 BA ED 50 C3 9C 22   C3 5E FB B4 42 78 CA FE  ....P..".^..Bx..
0010: 79 C2 1B 86 1E E9 71 41   42 81 34 ED 62 81 F5 44  y.....qAB.4.b..D
0020: 7C D6 60 FB 45 30 E7 9C   78 00 75 11 AB 17 44 C9  ..`.E0..x.u...D.
Client MAC write Secret:
0000: 3C 72 A9 F1 8A 3B ED 81   E8 5C 83 C3 43 75 B3 E5  <r...;...\..Cu..
Server MAC write Secret:
0000: 6C F5 C5 0A B7 53 75 51   63 17 73 8F 89 7E AB 08  l....SuQc.s.....
Client write key:
0000: B7 DC 97 2D 7D A3 AA 63   56 AB CA 9D BD 31 E8 8B  ...-...cV....1..
Server write key:
0000: A2 94 D9 BF F4 CA 81 0D   7B F2 E1 FA 9A 78 5F E4  .............x_.
... no IV for cipher
[read] MD5 and SHA1 hashes:  len = 74
0000: 02 00 00 46 03 01 5B 90   E0 89 3E 2C 30 63 F4 A9  ...F..[...>,0c..
0010: D3 10 9F 01 E9 24 CC 68   AA BE 20 A5 5A 1B 59 00  .....$.h.. .Z.Y.
0020: 76 99 8A A3 16 90 20 00   00 00 00 3D 53 F5 93 03  v..... ....=S...
0030: 05 A6 29 71 30 52 6C E4   B8 AF 1D 08 5B 6F 16 32  ..)q0Rl.....[o.2
0040: 7B 3A 4E 34 02 3A C3 00   03 00                    .:N4.:....
ExecuteThread-39, READ:  SSL v3.1 Change Cipher

Comments
EVALUATION mayank.upadhyay@eng 2001-02-26 Please send the complete debugging output. The HelloRequest that you see is an indication that the server has asked the client to renegotiate the session. It appears that something happens during this renegotiation that makes the client disconnect. The debugging output might give some sort of clue. 7 Mar 2001, kevin.ryan@eng -- user has provided new info (see attachments and comments) bradford.wetmore@eng 2001-05-24 The handshaking flow of control seems to be going ok. On the renegotiation they are both sending their changeCipher followed by the finished. But for some reason the server isn't liking what it sees, and is asking for the client to start a re-renegotiation immediately. This could be a bug in the MS code also. Will need to play with it more to see what's going on... I don't know LDAP, but is it possible to get the socket, then grab the session, then invalidate it in order to force a renegotiation of the session? I doubt it's Linux related, but don't know for sure... bradford.wetmore@eng 2001-05-28 Rosanna adds in private email: The problem is not Linux specific. ----- A couple of other customers reported the same problem. They were able to resolve the problem by using RSA's SSLSocket. Another fixed it by using IBM's JNDI and SSL impl. It might be a timing issue because one customer reported that the problem is reproducible only with remote clients, not clients on the same Windows box. ----- JSSE doesn't create threads to handle handshaking, so I don't think this is the issue. Rosanna later adds: Customer says the same client code will work against the Netscape Directory. All reports I've seen say the problem arises only when the server is Active Directory and the client is Sun's SSL provider. Other combos of servers and SSL providers don't have this problem. Then: I tried to reproduce the problem against an Windows XP server but couldn't. Neither 1.3.1 nor 1.4.0 exhibits this problem. I'll see if I can find a Windows 2k machine with SSL set up. That's where things stand at this point. It may be that the Win2K machine has a broken SSL resumption code path. If that's the case, then there should be a bug filed against their code, and this bug can be closed on our side. Unless there is strong case, we don't want to special case our code to work around other's broken code. There were other customer reports on the jndi-interest list. bradford.wetmore@eng 2001-05-28 The problem is reproducible. A client on the same machine as Active Directory renegotiates fine. Any remote client (Windows, Linux, Solaris) fails. As mentioned before, the renegotiate seems to finish successfully but the server sends a HelloRequest after that, and then closes the connection. Even if client sends Hello, connection is already dead. rosanna.lee@eng 2001-07-18 From: Andreas Sterbenz <###@###.###> Bottom line is that this very much appears to be a Microsoft bug, they do not seem to handle handshake data and application data in the same TCP packet correctly. If I insert a sleep(350) after we sent the Finished message, the problem goes away, presumably because the data gets packaged into different packets by the OS then (smaller sleep values do not avoid the problem consistently). It only happens on resumed connections because in the full handshake the message order is different. From: Rosanna Lee <###@###.###> When Microsoft puts in a fix to their server to handle the case where the client is sending some application data in the same packet as the final handshake message, the problem goes away. Newer versions of Active Directory will not have this problem (probably XP FCS). ###@###.### 2001-08-29
29-08-2001

WORK AROUND Name: krC82822 Date: 02/10/2001 Using stunnel instead of JSSE; JNDI is pointed to the stunnel listening machine:port and SECURITY_PROTOCOL is not set to "ssl". ====================================================================== Use your own socket factory that does not reuse cached sessions. rosanna.lee@eng 2001-07-18
18-07-2001