[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Netscape to slapd with SSL anonymous OK, login fails



I have run another series of tests and compared the logs for two cases:

A    SSL without login
B    SSL with login but with nothing entered in the boxes for login/password

slapd's log declares both as anonymous.

The logs are identical except for the tls_write data which I presume will be
different because of the negotiated encryption.

I think this is Netscape bug.

Did you find a client that does do authenticated SSL?


----- Original Message -----
From: "Julio Sánchez Fernández" <j_sanchez@stl.es>
To: "Jim Hud" <jdhz@btinternet.com>
Cc: <openldap-software@OpenLDAP.org>
Sent: Monday, October 16, 2000 9:18 AM
Subject: Re: Netscape to slapd with SSL anonymous OK, login fails


>
>
> Jim Hud wrote:
> >
> > Julio, are you of the view that this is more likely to be a Netscape
> > problem?
>
> I simply don't know.  We seem to get a correct request for a v2
> anonymous bind and we seem to build a correct response at the
> LDAP BER layer.  Now we put that through TLS and the client
> ends up seeing something different.  So, it should be the client,
> right?  But it might be that we have unflushed data in the TLS
> connection that goes out prepended to our response.
>
> On the other hand, it might be something completely different.
> Notice this:
>
> >   0000:  30 0c 02 01 01 61 07 0a  01 00 04 00 04 00
0....a........
>
> The error code is an enumerated and those are tagged with 0a.
> For that 61 to be mistaken for the error code, Netscape would
> have to be taking the group 01 01 67 (a boolean of length one
> and value 0x67 of all things) and take it for an enumerated.
> Too sloppy a coding to consider it a plausible error.  Occam's
> razor does not allow it.
>
> On the hand, the 0x61 coincidence is too tempting to ignore.
>
> Notice that it is unlikely that the error happens in the TLS
> flow, since data would probably get corrupted hopelessly.
> Wait, maybe that is exactly what is happening: complete data
> corruption and 0x61 happens just by chance.
>
> Anyone knows how to debug TLS data flows?
>
> Julio
>