On Tue, Aug 13, 2002 at 07:45:30PM +0200, Bodo Moeller wrote:
> On Tue, Aug 13, 2002 at 05:10:34PM +0100, Ben Laurie wrote:
> > Yes, and the application will continue as if it were sensible to do so.
>
> In fact it *is* often sensible to do so because such supposedly
> "impossible events" are triggered by certain conditions (such as
> unusual parameters in a certain protocol version) that will not apply
> to all connections. In such cases we cannot continue the one
> connection where a potential buffer overflow was detected, but there's
> no reason to completely kill the application. The internal error
> terminates the single connection for which OpenSSL does not know how
> to continue. There is no reason why this should affect the rest of
> the program.
I think we should define our terms clearly.
For me an "internal error" is an error that must not occur at all and
that can only have appeared due to the library having failed somehow
such that an inconistent state occurs (in M$-notation: "an unexpected
error occured" :-). I consider an error like this to be fatal and think
that it is still sensible to abort().
By definition we have no explanation on how this could happen and so
we don't know how to continue.
Example: when working through the internal session cache we learn, that
the linked list is corrupted, we have dangling pointers and don't know
what is going on. This would touch all threads using the same SSL_CTX.
Thus: we don't know how to repair it -> abort().
If we have protocol errors to catch or errors in using the API (a function,
even an internal one was called with incorrect parameters, maybe a string
is too long), we can oversee the error and its impact, prevent the impact
and return with a corresponding failure message. We do this for a large part
of the public API, so we can also build in additional safety nets that
generate error messages and consequently result in a "normal" handshake
failure.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
