On Wed, Jun 23, 1999 at 08:02:28AM +0200, Arne Ansper wrote:
> Bodo Moeller:
>> It will work with the current implementation (but only if the
>> applications don't do too stupid things, such as point to a buffer
>> with different contents); but this may change.
> if the application does stupid things (i.e. does not check return value of
> write/SSL_write/whatever) then it should be fixed. this check will not fix
> them. instead, it just makes properly written programms to fail
> undeterministically.
This depends on how you define "properly written", obviously. If you
specify that SSL_read and SSL_write, if reporting SSL_ERROR_WANT_...,
have to be called with exactly the same parameters until they return
something non-negative or a proper error, then properly written
programs won't have problems. Given that the current API works that
way (well, I assume that growing read and write buffers is no problem
as long as their locations does not change), you now *have* to make
that assumption, although of course it is possible to weaken the
requirements of the API -- similar to what we did for compatibility
with all those applications that did not make the previously required
call to SSL_set_{accept,connect}_state.
Incorrectly written programs that would apparently work if the check
were not there but will produce "inexplainable" errors under certain
(rare) conditions would be those that pass a different pointer to
SSL_write for the retry and have not copied all of the previous data
(e.g. copying in the wrong direction -- things like that happen
occasionally). Usually the failure to do so will not be noticed
because SSL_write does not re-examine the contents of the write
buffer; but if the data takes more than one TLS record, things will go
wrong. This case could well escape testing. For similar reasons, we
require session ID contexts even if no external cache is used. While
it is true that buggy applications must be fixed, it is also valuable
to design the library in a way such that application bugs are likely
to show up during tests.
Of course also the advantages of allowing moving the buffer must be
considered. Because the buffer now must stay at the same location,
you also cannot grow it. This means that if you start a 17 K write
which blocks, then you have to write that data in one 16 K record
(maximum record size) and one 1 K record, even though you may have
additional data for writing once you start writing the second record.
There are two possibilities for how this could be changed:
1. Have SSL_write return after each single record, returing the number of
bytes written so far.
2. Allow applications to move the write buffer between calls to SSL_write.
(Obviously we could also do both.) The first change might break
existing applications that rely on SSL_write not reporting success
until it has written all of the available data -- unfortunately there
is no written specification that declares that SSL_write may return
earlier and report partial success, although most applications are
sane enough to prepare for that possibility. Apart from this concern,
the first approach makes much more sense than the second one because
by growing the write buffer the application may end up repeatedly
copying a huge buffer that consists mostly of data that has long been
written over the network.
What we certainly could do is offer two options to enable behaviour 1
and/or behaviour 2, so that applications can formally state that they
know what they are doing.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
