OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Enhancements/3037
Full headers

From: boba@softerra.com
Subject: Start TLS operation issue
Compose comment
Download message
State:
0 replies:
9 followups: 1 2 3 4 5 6 7 8 9

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 24 Mar 2004 13:41:14 GMT
From: boba@softerra.com
To: openldap-its@OpenLDAP.org
Subject: Start TLS operation issue
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.


Followup 1

Download message
Date: Wed, 24 Mar 2004 10:31:38 -0800
To: boba@softerra.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: Start TLS operation issue (ITS#3037)
Cc: openldap-its@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.



Followup 2

Download message
From: "Dimson" <boba@softerra.com>
To: <openldap-its@OpenLDAP.org>
Subject: Re: Start TLS operation issue (ITS#3037)
Date: Tue, 30 Mar 2004 12:46:10 +0300
>> We are pretty liberal in accepting the other 8 octets
>> of bogusity in the PDU

Do you mean that the latest version of your server will accept such message
formed by MS or Netscape API?

>> 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)

I don't think there will be any problems. Tests with Novell server revealed
that client accepts properly formed responses. And even if it wasn't so it
couldn't be a problem of OpenLDAP server anyway. But the fact is that there
is no possibility to send extended request to OpenLDAP server with help of
two most popular client LDAP APIs (MS, Natscape).

Thanx in advance.
Dmitry



Followup 3

Download message
Date: Thu, 01 Apr 2004 21:09:41 -0800
To: boba@softerra.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: Start TLS operation issue (ITS#3037)
Cc: openldap-its@OpenLDAP.org
At 01:46 AM 3/30/2004, boba@softerra.com wrote:
>But the fact is that there
>is no possibility to send extended request to OpenLDAP server with help of
>two most popular client LDAP APIs (MS, Natscape). 

I note that if these API implementations are not capable of
sending an LDAP extended request without extension data,
they are significantly flawed.  That is, you should report
a bug to the developers of these API implementations.

Your request to be liberal here remains under consideration.

Kurt 



Followup 4

Download message
From: "Dimson" <boba@softerra.com>
To: <openldap-its@OpenLDAP.org>
Subject: Re: Start TLS operation issue (ITS#3037)
Date: Wed, 28 Apr 2004 18:48:53 +0300
Hello,
With all respect let me draw your attention to the fact that practically
this situation leads us to the absence of interoperability between OpenLDAP
server and huge amount of client installations that are already took their
place and it's hardly possible now to update any of them.
Thanx again.
Dmitry



Followup 5

Download message
Date: Thu, 27 May 2004 07:51:47 -0700
To: "Kirill Kovalenko" <kirill@softerra.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: StartTLS issues (ITS#3037)
Cc: <openldap-its@OpenLDAP.org>
In this response, which I forward to <openldap-its> with
an appropriate subject so it will be attached to the ITS,
I'll discuss only the ITS#3037 issue.  The other issue
should be separately discussed as part of ITS#1590.

I believe the first to resolving this issue should be to
report the bugs in the APIs to the API developers.  Once
aware of the problem, I suspect they would fix their bug.
It's unclear to me whether the original submitter of
ITS#3037 ever attempted to report the bugs to the API
developers.

While this particular bug doesn't directly affect me (as I
don't use any of the APIs mentioned), I did notified Mozilla
LDAP folks of their bug and they fixed it quickly.  I'll
leave the reporting and tracking of bug reports with
vendor-developed APIs to those who have relationships with
those vendors.  I assume they will fix their bugs in a
reasonable amount of time.

Have you (or anyone else) reported the problem to Microsoft?
If so, what did they say they would do about it?

I'm not warm to the idea of adding a workaround in the
meantime.  I would be more receptive to the idea if I knew that
the bug was reported to the vendors and the vendors agreed
that it was a bug and agreed to fix it (hence my encouragement
to report these API implementation bugs to the API developers).
I'm quite concerned that if we don't get them to fix their bug
now, we'll have repeats of this problem with numerous other
extended operations, like WhoAmI?, which send no data in
requests.

Kurt



At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
>Hello,
>
>We've spent some time digging into the issue. Here is the results; 
>
>1. Request
>
>The following table illustrates how parameters passed to the
>ldap_extended_operation_s() influence upon the ANS.1 data being transferred
>on wire.
>
>Client API    |ldap_extended_operation_s()           | Sent Message
>=======================================================================
>OpenLDAP      | requestdata = NULL                         | w/o data octets
>-----------------------------------------------------------------------
>OpenLDAP      | requestdata = struct berval{0, NULL} | an empty berval
>-----------------------------------------------------------------------
>Netscape      | requestdata = NULL                   | N/A (crash)
>-----------------------------------------------------------------------
>Netscape      | requestdata = struct berval{0, NULL} | the empty berval
>-----------------------------------------------------------------------
>Microsoft     | requestdata = NULL                   | the empty berval
>-----------------------------------------------------------------------
>Microsoft     | requestdata = struct berval{0, NULL} | the empty berval
>----------------------------------------------------------------------- 
>
>Form this table you can see that Netscape and Microsoft API always send
>empty an berval structure even if request data has to be absent (i.e. NULL).
>
>Unfortunately, OpenLDAP server does not accept such requests for the
>'StartTLS' extended operation because of the following code:
>
>starttls.c (starttls_extop() function):
>
>        if ( op->ore_reqdata != NULL ) {
>                /* no request data should be provided */
>                rs->sr_text = "no request data expected";
>                return LDAP_PROTOCOL_ERROR;
>        }
>
>This code makes it impossible to execute 'StartTLS' operation if it is made
>by clients who compiled against Netscape or Microsoft APIs. (The same is
>true for the 'Who Am I' operation)
>
>The fix for the problem is trivial: 
>
>        if ( op->ore_reqdata != NULL &&
op->ore_reqdata->bv_len > 0) {
>                /* no request data should be provided */
>                rs->sr_text = "no request data expected";
>                return LDAP_PROTOCOL_ERROR;
>        }
>
>We completely understand that this workaround contradicts RFC2830
>(Lightweight Directory Access Protocol (v3): Extension for Transport Layer
>Security)
>saying:
>...
>   A Start TLS extended request is formed by setting the requestName
>   field to the OID string given above.  The requestValue field is
>   absent.
>...
>Still, we believe that the fix should be applied because of the huge amount
>of mentioned clients installed worldwide.



Followup 6

Download message
From: "Kirill Kovalenko" <kirill@softerra.com>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: <openldap-its@OpenLDAP.org>
Subject: RE: StartTLS issues (ITS#3037)
Date: Thu, 27 May 2004 18:20:22 +0300
Kurt,

> Have you (or anyone else) reported the problem to Microsoft?

Yes, I have.
http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se
ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off

As you can see the status is unclear for now.

Kirill

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
> Sent: Thursday, May 27, 2004 5:52 PM
> To: Kirill Kovalenko
> Cc: openldap-its@OpenLDAP.org
> Subject: Re: StartTLS issues (ITS#3037)
> 
> 
> In this response, which I forward to <openldap-its> with
> an appropriate subject so it will be attached to the ITS,
> I'll discuss only the ITS#3037 issue.  The other issue
> should be separately discussed as part of ITS#1590.
> 
> I believe the first to resolving this issue should be to
> report the bugs in the APIs to the API developers.  Once
> aware of the problem, I suspect they would fix their bug.
> It's unclear to me whether the original submitter of
> ITS#3037 ever attempted to report the bugs to the API developers.
> 
> While this particular bug doesn't directly affect me (as I 
> don't use any of the APIs mentioned), I did notified Mozilla 
> LDAP folks of their bug and they fixed it quickly.  I'll 
> leave the reporting and tracking of bug reports with 
> vendor-developed APIs to those who have relationships with 
> those vendors.  I assume they will fix their bugs in a 
> reasonable amount of time.
> 
> Have you (or anyone else) reported the problem to Microsoft?
> If so, what did they say they would do about it?
> 
> I'm not warm to the idea of adding a workaround in the 
> meantime.  I would be more receptive to the idea if I knew 
> that the bug was reported to the vendors and the vendors 
> agreed that it was a bug and agreed to fix it (hence my 
> encouragement to report these API implementation bugs to the 
> API developers). I'm quite concerned that if we don't get 
> them to fix their bug now, we'll have repeats of this problem 
> with numerous other extended operations, like WhoAmI?, which 
> send no data in requests.
> 
> Kurt
> 
> 
> 
> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
> >Hello,
> >
> >We've spent some time digging into the issue. Here is the results;
> >
> >1. Request
> >
> >The following table illustrates how parameters passed to the
> >ldap_extended_operation_s() influence upon the ANS.1 data being 
> >transferred on wire.
> >
> >Client API    |ldap_extended_operation_s()           | Sent Message
> >=============================================================
> ==========
> >OpenLDAP      | requestdata = NULL                         | 
> w/o data octets
> >-------------------------------------------------------------
> ----------
> >OpenLDAP      | requestdata = struct berval{0, NULL} | an 
> empty berval
> >-------------------------------------------------------------
> ----------
> >Netscape      | requestdata = NULL                   | N/A (crash)
> >-------------------------------------------------------------
> ----------
> >Netscape      | requestdata = struct berval{0, NULL} | the 
> empty berval
> >-------------------------------------------------------------
> ----------
> >Microsoft     | requestdata = NULL                   | the 
> empty berval
> >-------------------------------------------------------------
> ----------
> >Microsoft     | requestdata = struct berval{0, NULL} | the 
> empty berval
> >-------------------------------------------------------------
> ----------
> >
> >Form this table you can see that Netscape and Microsoft API 
> always send 
> >empty an berval structure even if request data has to be 
> absent (i.e. 
> >NULL).
> >
> >Unfortunately, OpenLDAP server does not accept such requests for the 
> >'StartTLS' extended operation because of the following code:
> >
> >starttls.c (starttls_extop() function):
> >
> >        if ( op->ore_reqdata != NULL ) {
> >                /* no request data should be provided */
> >                rs->sr_text = "no request data expected";
> >                return LDAP_PROTOCOL_ERROR;
> >        }
> >
> >This code makes it impossible to execute 'StartTLS' 
> operation if it is 
> >made by clients who compiled against Netscape or Microsoft 
> APIs. (The 
> >same is true for the 'Who Am I' operation)
> >
> >The fix for the problem is trivial:
> >
> >        if ( op->ore_reqdata != NULL && 
> op->ore_reqdata->bv_len > 0) {
> >                /* no request data should be provided */
> &g

Message of length 5701 truncated


Followup 7

Download message
Date: Thu, 27 May 2004 08:41:08 -0700
To: "Kirill Kovalenko" <kirill@softerra.com>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: StartTLS issues (ITS#3037)
Cc: <openldap-its@OpenLDAP.org>
Is this newsgroup a formal bug reporting mechanism?

At 08:20 AM 5/27/2004, Kirill Kovalenko wrote:
>Kurt,
>
>> Have you (or anyone else) reported the problem to Microsoft?
>
>Yes, I have.
>http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se
>ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off
>
>As you can see the status is unclear for now.
>
>Kirill
>
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
>> Sent: Thursday, May 27, 2004 5:52 PM
>> To: Kirill Kovalenko
>> Cc: openldap-its@OpenLDAP.org
>> Subject: Re: StartTLS issues (ITS#3037)
>> 
>> 
>> In this response, which I forward to <openldap-its> with
>> an appropriate subject so it will be attached to the ITS,
>> I'll discuss only the ITS#3037 issue.  The other issue
>> should be separately discussed as part of ITS#1590.
>> 
>> I believe the first to resolving this issue should be to
>> report the bugs in the APIs to the API developers.  Once
>> aware of the problem, I suspect they would fix their bug.
>> It's unclear to me whether the original submitter of
>> ITS#3037 ever attempted to report the bugs to the API developers.
>> 
>> While this particular bug doesn't directly affect me (as I 
>> don't use any of the APIs mentioned), I did notified Mozilla 
>> LDAP folks of their bug and they fixed it quickly.  I'll 
>> leave the reporting and tracking of bug reports with 
>> vendor-developed APIs to those who have relationships with 
>> those vendors.  I assume they will fix their bugs in a 
>> reasonable amount of time.
>> 
>> Have you (or anyone else) reported the problem to Microsoft?
>> If so, what did they say they would do about it?
>> 
>> I'm not warm to the idea of adding a workaround in the 
>> meantime.  I would be more receptive to the idea if I knew 
>> that the bug was reported to the vendors and the vendors 
>> agreed that it was a bug and agreed to fix it (hence my 
>> encouragement to report these API implementation bugs to the 
>> API developers). I'm quite concerned that if we don't get 
>> them to fix their bug now, we'll have repeats of this problem 
>> with numerous other extended operations, like WhoAmI?, which 
>> send no data in requests.
>> 
>> Kurt
>> 
>> 
>> 
>> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
>> >Hello,
>> >
>> >We've spent some time digging into the issue. Here is the results;
>> >
>> >1. Request
>> >
>> >The following table illustrates how parameters passed to the
>> >ldap_extended_operation_s() influence upon the ANS.1 data being 
>> >transferred on wire.
>> >
>> >Client API    |ldap_extended_operation_s()           | Sent Message
>> >=============================================================
>> ==========
>> >OpenLDAP      | requestdata = NULL                         | 
>> w/o data octets
>> >-------------------------------------------------------------
>> ----------
>> >OpenLDAP      | requestdata = struct berval{0, NULL} | an 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Netscape      | requestdata = NULL                   | N/A (crash)
>> >-------------------------------------------------------------
>> ----------
>> >Netscape      | requestdata = struct berval{0, NULL} | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Microsoft     | requestdata = NULL                   | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Microsoft     | requestdata = struct berval{0, NULL} | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >
>> >Form this table you can see that Netscape and Microsoft API 
>> always send 
>> >empty an berval structure even if request data has to be 
>> absent (i.e. 
>> >NULL).
>> >
>> >Unfortunately, OpenLDAP server does not accept such requests for
the 
>> >'StartTLS' extended operation because of the following code:
>> >
>> >starttls.c (starttls_extop() function):
>> >
>> >        if ( op->ore_reqdata != NULL ) {
>> >                /* no request data should be provided */
>> >                rs->sr_text = "no request data expected";
>> >      

Message of length 6360 truncated


Followup 8

Download message
From: "Kirill Kovalenko" <kirill@softerra.com>
To: "'Kurt D. Zeilenga'" <Kurt@OpenLDAP.org>
Cc: <openldap-its@OpenLDAP.org>
Subject: RE: StartTLS issues (ITS#3037)
Date: Thu, 27 May 2004 18:51:27 +0300
Kurt,

Well I'm not sure. I was told by an insider to post it there and I
definitely don't want to pay $99 for their official support request. 

Kirill

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
> Sent: Thursday, May 27, 2004 6:41 PM
> To: Kirill Kovalenko
> Cc: openldap-its@OpenLDAP.org
> Subject: RE: StartTLS issues (ITS#3037)
> 
> 
> Is this newsgroup a formal bug reporting mechanism?
> 
> At 08:20 AM 5/27/2004, Kirill Kovalenko wrote:
> >Kurt,
> >
> >> Have you (or anyone else) reported the problem to Microsoft?
> >
> >Yes, I have. 
> >http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf
> 9a3c907b33
> >b6&se
> >ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off
> >
> >As you can see the status is unclear for now.
> >
> >Kirill
> >
> >> -----Original Message-----
> >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> >> Sent: Thursday, May 27, 2004 5:52 PM
> >> To: Kirill Kovalenko
> >> Cc: openldap-its@OpenLDAP.org
> >> Subject: Re: StartTLS issues (ITS#3037)
> >> 
> >> 
> >> In this response, which I forward to <openldap-its> with
> >> an appropriate subject so it will be attached to the ITS, I'll 
> >> discuss only the ITS#3037 issue.  The other issue should be 
> >> separately discussed as part of ITS#1590.
> >> 
> >> I believe the first to resolving this issue should be to 
> report the 
> >> bugs in the APIs to the API developers.  Once aware of the 
> problem, I 
> >> suspect they would fix their bug. It's unclear to me whether the 
> >> original submitter of ITS#3037 ever attempted to report 
> the bugs to 
> >> the API developers.
> >> 
> >> While this particular bug doesn't directly affect me (as I
> >> don't use any of the APIs mentioned), I did notified Mozilla 
> >> LDAP folks of their bug and they fixed it quickly.  I'll 
> >> leave the reporting and tracking of bug reports with 
> >> vendor-developed APIs to those who have relationships with 
> >> those vendors.  I assume they will fix their bugs in a 
> >> reasonable amount of time.
> >> 
> >> Have you (or anyone else) reported the problem to 
> Microsoft? If so, 
> >> what did they say they would do about it?
> >> 
> >> I'm not warm to the idea of adding a workaround in the
> >> meantime.  I would be more receptive to the idea if I knew 
> >> that the bug was reported to the vendors and the vendors 
> >> agreed that it was a bug and agreed to fix it (hence my 
> >> encouragement to report these API implementation bugs to the 
> >> API developers). I'm quite concerned that if we don't get 
> >> them to fix their bug now, we'll have repeats of this problem 
> >> with numerous other extended operations, like WhoAmI?, which 
> >> send no data in requests.
> >> 
> >> Kurt
> >> 
> >> 
> >> 
> >> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
> >> >Hello,
> >> >
> >> >We've spent some time digging into the issue. Here is the
results;
> >> >
> >> >1. Request
> >> >
> >> >The following table illustrates how parameters passed to the
> >> >ldap_extended_operation_s() influence upon the ANS.1 data
being
> >> >transferred on wire.
> >> >
> >> >Client API    |ldap_extended_operation_s()           | 
> Sent Message
> >> >=============================================================
> >> ==========
> >> >OpenLDAP      | requestdata = NULL                         | 
> >> w/o data octets
> >> >-------------------------------------------------------------
> >> ----------
> >> >OpenLDAP      | requestdata = struct berval{0, NULL} | an 
> >> empty berval
> >> >-------------------------------------------------------------
> >> ----------
> >> >Netscape      | requestdata = NULL                   | N/A
(crash)
> >> >-------------------------------------------------------------
> >> ----------
> >> >Netscape      | requestdata = struct berval{0, NULL} | the 
> >> empty berval
> >> >-------------------------------------------------------------
> >> ----------
> >> >Microsoft     | requestdata = NULL                   | the 
> >> empty berval
> >> >-------------------------------------------------------------

Message of length 7545 truncated


Followup 9

Download message
Date: Thu, 27 May 2004 09:03:58 -0700
To: kirill@softerra.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: RE: StartTLS issues (ITS#3037)
Cc: openldap-its@OpenLDAP.org
Your description of 4) which relates to this issue is misleading.
The issue is not with their encoding of empty data, but their
inability to encode a PDU with no data.  empty != no (much like
"" != NULL in C).

Kurt

At 08:21 AM 5/27/2004, kirill@softerra.com wrote:
>Kurt,
>
>> Have you (or anyone else) reported the problem to Microsoft?
>
>Yes, I have.
>http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se
>ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off
>
>As you can see the status is unclear for now.
>
>Kirill
>
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
>> Sent: Thursday, May 27, 2004 5:52 PM
>> To: Kirill Kovalenko
>> Cc: openldap-its@OpenLDAP.org
>> Subject: Re: StartTLS issues (ITS#3037)
>> 
>> 
>> In this response, which I forward to <openldap-its> with
>> an appropriate subject so it will be attached to the ITS,
>> I'll discuss only the ITS#3037 issue.  The other issue
>> should be separately discussed as part of ITS#1590.
>> 
>> I believe the first to resolving this issue should be to
>> report the bugs in the APIs to the API developers.  Once
>> aware of the problem, I suspect they would fix their bug.
>> It's unclear to me whether the original submitter of
>> ITS#3037 ever attempted to report the bugs to the API developers.
>> 
>> While this particular bug doesn't directly affect me (as I 
>> don't use any of the APIs mentioned), I did notified Mozilla 
>> LDAP folks of their bug and they fixed it quickly.  I'll 
>> leave the reporting and tracking of bug reports with 
>> vendor-developed APIs to those who have relationships with 
>> those vendors.  I assume they will fix their bugs in a 
>> reasonable amount of time.
>> 
>> Have you (or anyone else) reported the problem to Microsoft?
>> If so, what did they say they would do about it?
>> 
>> I'm not warm to the idea of adding a workaround in the 
>> meantime.  I would be more receptive to the idea if I knew 
>> that the bug was reported to the vendors and the vendors 
>> agreed that it was a bug and agreed to fix it (hence my 
>> encouragement to report these API implementation bugs to the 
>> API developers). I'm quite concerned that if we don't get 
>> them to fix their bug now, we'll have repeats of this problem 
>> with numerous other extended operations, like WhoAmI?, which 
>> send no data in requests.
>> 
>> Kurt
>> 
>> 
>> 
>> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
>> >Hello,
>> >
>> >We've spent some time digging into the issue. Here is the results;
>> >
>> >1. Request
>> >
>> >The following table illustrates how parameters passed to the
>> >ldap_extended_operation_s() influence upon the ANS.1 data being 
>> >transferred on wire.
>> >
>> >Client API    |ldap_extended_operation_s()           | Sent Message
>> >=============================================================
>> ==========
>> >OpenLDAP      | requestdata = NULL                         | 
>> w/o data octets
>> >-------------------------------------------------------------
>> ----------
>> >OpenLDAP      | requestdata = struct berval{0, NULL} | an 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Netscape      | requestdata = NULL                   | N/A (crash)
>> >-------------------------------------------------------------
>> ----------
>> >Netscape      | requestdata = struct berval{0, NULL} | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Microsoft     | requestdata = NULL                   | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Microsoft     | requestdata = struct berval{0, NULL} | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >
>> >Form this table you can see that Netscape and Microsoft API 
>> always send 
>> >empty an berval structure even if request data has to be 
>> absent (i.e. 
>> >NULL).
>> >
>> >Unfortunately, OpenLDAP server does not accept such requests for
the 
>> >'StartTLS' extended operation because of the following code:
>> >
>> >starttls.c (starttls_extop() function):
>> >
>> >        if ( op->ore_reqdata != NULL 

Message of length 6527 truncated

Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org