Re: FW: is the ssl3_send_alert() function public ( part of the API )? (ITS#1954)

[kervin@blueprint-tech.com]

Well at least we are on the same page about the function being private.

The current issue is, can we trust that it is safe to continue using 
this OpenSSL private function.

I think generally using any functions not explicitly part of the API is 
a risky venture.  This is generally speaking, but I think it is a good 
policy to avoid this.

The OpenSSL developers can choose to change the internal workings, 
side-effects, etc. of this function at any time without any 
notification.  Users would learn about it the hard way if the change is 
subtle.

Also if OpenSSL programmers start only exporting the API functions ( 
believe you can do this with most ld's, it's just not the default ), we 
would lose this function as well.

What were OpenLDAP API users who relied on the LDAP connection structure 
members being directly accessible told?  A very hash "you shouldn't be 
doing this!" :)

Anyhow, it's a very minor issue so I'm going to stop spamming the list 
about it now.

But it still breaks the MSVC build :(

--Kervin


Howard Chu wrote:
> Looks like the ITS is still out of disk space. I will post a final followup
> when things clear up. Feel free to comment on the text below:
> 
> or the ITS record: this function will only be invoked when
> tls_opt_require_cert is set to LDAP_OPT_X_TLS_ALLOW and cert verification
> failed. In the normal case, the verify callback will fail the handshake when
> any error is detected, and the connection will be dropped. re: security
> issues, you already have security issues if you choose to explicitly
> configure TLS_ALLOW and allow TLS sessions to progress after a failed cert
> verification. That is a decision that you consciously choose. At least with
> this code in place, you will see a warning that something wasn't quite right.
> Removing this warning means no diagnostic at all, which I believe is a
> greater liability.
> 
> The results are not indeterminate, the function does not get invoked until
> long after the handshake has completed. Your concerns are completely
> unfounded.
> 
> I feel compelled to point out that I've been working with SSLeay/OpenSSL
> since 1996, longer than any of the current OpenSSL team members. This API has
> existed since 0.8.0 and having survived this long, isn't likely to ever
> change.
> 
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
> 
> 
>>-----Original Message-----
>>From: Kervin L. Pierre [mailto:kervin@blueprint-tech.com]
>>Sent: Tuesday, July 16, 2002 11:55 AM
>>To: Howard Chu; openldap-its
>>Subject: Re: FW: is the ssl3_send_alert() function public ( part of the
>>API )? (ITS#1954)
>>
>>
>>
>>Submitting the request is a good idea.
>>
>>But I doubt the api change, if any, would be made before a new release
>>of OpenSSL.  In the mean time, is it a good idea to continue using that
>>private function?  The results are indeterminant and this *is* the
>>security layer.
>>
>>I think the mixture of users using, different versions of OpenLDAP,
>>OpenSSL, and OSes may be lead eventually to a possible security issue.
>>
>>--Kervin
>>
>>
>>Howard Chu wrote:
>>
>>>The API is deficient. I will submit the request to their tracker.
>>>
>>>  -- Howard Chu
>>>  Chief Architect, Symas Corp.       Director, Highland Sun
>>>  http://www.symas.com               http://highlandsun.com/hyc
>>>  Symas: Premier OpenSource Development and Support
>>>
>>>-----Original Message-----
>>>From: Lutz Jaenicke [mailto:Lutz.Jaenicke@aet.TU-Cottbus.DE]
>>>Sent: Tuesday, July 16, 2002 10:51 AM
>>>To: Howard Chu
>>>Subject: Re: is the ssl3_send_alert() function public ( part of the API
>>>)?
>>>
>>>
>>>On Tue, Jul 16, 2002 at 10:35:38AM -0700, Howard Chu wrote:
>>>
>>>
>>>>Since alerts are defined by the SSLv3 spec this seems to be a glaring
>>>>omission from the exported API. In particular, there is no way for the
>>>>verify callback to send a warning to the other side without this
>>>
>>function,
>>
>>>>and simply making the callback return "not OK" results in a fatal
>>>>condition, instead of a warning.
>>>
>>>
>>>Hmm. Interesting suggestion. Some of the alerts must always be fatal
>>>according to the spec, but not all of them. I don't think that the
>>>application should ever send an alert itself (I think that it would mess
>>>up the complete control structure with respect to non-blocking etc.)
>>>It might however be possible to introduce some variable/flag that
>>>one can set inside the callback function. Currently only SUCCESS/FAIL
>>>can be signalled via the return value of the callback(). Of course,
>>>an addition like this one should be compatible with respect to the
>>>current API...
>>>
>>>Hmm. Maybe you should send a corresponding request to rt@openssl.org
>>>such that the idea is recorded in the request tracker.
>>>
>>>Best regards,
>>>	Lutz
>>
> 
>