On the authenticated SSL access from Netscape problem

[Julio Sánchez Fernández <j_sanchez@stl.es>]

A *very* interesting tool has been released, namely, an SSL sniffer
called ssldump.  Of course, it needs your keys to look into the
encrypted data stream, but this is just what we needed to kill
this problem.

I have run it and I get at the end:

<some material removed...>
1 10 0.1955 (0.0007)  C>SV3.0(30)  application_data    data[14]=
      30 0c 02 01 01 60 07 02 01 02 04 00
      80 00
1 11 0.1971 (0.0015)  S>CV3.0(30)  application_data    data[14]=
      30 0c 02 01 01 61 07 0a 01 00 04 00
      04 00
1 12 3.2092 (3.0120)  C>SV3.0(23)  application_data    data[7]=
      30 05 02 01 03 42 00
1 13 3.2094 (0.0002)  C>SV3.0(18)  Alert
    level           warning
    value           close_notify
1    3.2094 (0.0000)  C>S  TCP FIN
1 14 3.2113 (0.0018)  S>CV3.0(18)  Alert
    level           warning
    value           close_notify

That is, our well known scenario where we tell the client to go
ahead on message 11 and the client just disconnects (the message
numbered 12 is an unbind request).  Of course, the client shows
our well known message 'Referral hop limit exceeded' (0x61).

So it is either a deep bug in OpenSSL (ssldump depends on it, so
we may be having a common mode error) or the bug is in Netscape.
Anyway, could someone with a Netscape server compile ssldump,
get a trace of the dialog between Communicator and the Directory
Server when using both 'Secure' and 'Login with Name and Password'
and post it?

This way we might make sure the problem is somewhere else or even
find a workaround if not too painful.

Oh, by the way, ssldump is at:

	http://www.rtfm.com/ssldump/

If you try it on Linux, use CPPFLAGS=-D_BSD_SOURCE or you will
have a hell of a time compiling it.  I run it like this:

	ssldump -A -d -k mykeyfile.key -p mypassphrase tcp port 636

Do make sure you get your -k and your -p right or it won't decode
the data stream and will not warn you.

Thanks in advance,

Julio