[Date Prev][Date Next]
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" <firstname.lastname@example.org>
To: "Jim Hud" <email@example.com>
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
> 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?