Re: Start TLS operation issue (ITS#3037)

[Kurt@OpenLDAP.org]

We are pretty liberal in accepting the other 8 octets of bogusity
in the PDU.  The problem I see here is that even if we were to
ignore the bogus empty sequence, would the client accept a properly
formed response (with no sequence).  That is, I don't mind being
liberal in what we accept, but we need to remain strict in what
we produce.

Kurt

At 05:41 AM 3/24/2004, boba@softerra.com wrote:
>Full_Name: Dmitry A.
>Version: 2.1.25
>OS: Linux RH 9.0
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (217.144.66.190)
>
>
>Hello. Let me make a reservation that under no circumstances this issue could be
>said is a bug of OpenLDAP server because it works pretty fine with ?native?
>(OpenLDAP) client. But at least it could be a subject for some improvements.
>
>So the issue concerns the Start TLS extended operation performed by other LDAP
>clients. When I use ldap_start_tls_s function of MS API client or perform an
>extended operation with START_TLS_OID (since there is no ldap_start_tls_s
>function at all) with help of Netscape API the server returns
>LDAP_PROTOCOL_ERROR accompanied with the message ?no request data expected?.
>Short investigation showed inconsistency on binary level of LDAP packets sent by
>OpenLDAP and other clients. Below is the hexadecimal representation of ASN1
>sequences for extended LDAP requests had been cut out from network packets.
>
>OpenLDAP API: 
>30 1D 02 01 01 77 18 80 16 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 2E 32
>30 30 33 37
>
>MS API, Netscape API:
>30 84 00 00 00 23 02 01 0E 77 84 00 00 00 1A 80 16 31 2E 33 2E 36 2E 31 2E 34 2E
>31 2E 31 34 36 36 2E 32 30 30 33 37 81 00
>
>ASN1 viewing tool revealed an empty ?redundant? tag at the end of the
>MS/Netscape API packets. I think it would be great if OpenLDAP server could be
>able to display more tolerance to such clients (like it does Novell server for
>example: www.nldap.com)
>
>With respect,
>Dmitry.