[Date Prev][Date Next]
RE: Netscape to slapd with SSL anonymous OK, login fails
Sounds like a question for the openssl-users mailing list. If there is any
incompatibility between OpenSSL and Netscape, it is probably already known.
However, this seems unlikely, given the huge number of Apache web servers
out there that successfully use OpenSSL/modssl, and the literally millions
of Netscape and Microsoft clients talking to them.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Julio Sánchez
> 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?