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

[hyc@highlandsun.com]

> -----Original Message-----
> From: Kervin L. Pierre [mailto:kervin@blueprint-tech.com]

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

I let that slide, but in fact there are several exported functions whose
names begin with lower-case chars. The distinction is not as concrete as
you would be led to believe.

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

Perhaps so; your definition of what is part of the API differs from mine.
Since I had a hand in creating the OpenSSL API I trust my definition more
than yours.

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

This is not a standard feature of Unix linkers. You cannot extrapolate how
the world works (or should work) based on the example set by Microsoft.

> 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!" :)

In the first UMich API, using the LDAP connection structure was *the*
documented way to interact with the library, as no accessor functions
existed. This is also a poor example.
>
> Anyhow, it's a very minor issue so I'm going to stop spamming the list
> about it now.

Thank you.

> But it still breaks the MSVC build :(

As I said before, it works with MinGW, and the fix is trivial. Get over it.

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

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support