On Tue, Aug 13, 2002 at 08:09:02PM +0200, Lutz Jaenicke wrote:
> 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().
This is an example of an internal error where we do not know how to
continue.
But for various other potential errors, we do know what happened
(e.g. a buffer has insufficient size) and we do know how to continue
without doing significant harm (abort this one TLS/SSL connection, and
in a way such that we have a likelihood of seeing a useful error
message in some log file). These are still "internal errors".
For example, here is a consistency check I added in April when I
implemented the empty fragment protocol weakness workaround
(ssl/s3_pkt.c):
if (s->s3->wbuf.len < (size_t)prefix_len +
SSL3_RT_MAX_PACKET_SIZE)
{
/* insufficient space */
SSLerr(SSL_F_DO_SSL3_WRITE, ERR_R_INTERNAL_ERROR);
goto err;
}
The buffer is allocated by the SSL library, but this happens
elsewhere, so it's safer not to rely on buffer allocation being
sufficient for what I plan to do with the buffer. If the buffer is
not sufficient, this would be a bug in OpenSSL.
> 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.
Yes, but we can also continue with a "normal" handshake failure for
various errors that are clearly internal.
--
Bodo Möller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
