On Thu, Nov 30, 2000 at 10:55:27AM -0800, Geoff Thorpe wrote:
>>> The more tricky issue is one of the SSL state itself ... in theory doing
>>> an SSL_peek() should allow some data to be generated but with a guarantee
>>> that the internal state is completely unchanged.
>> Should it? I'd have thought that what counts is that any application
>> data stays in the buffer for future SSL_read/peek() calls, [...]
> Well you're the expert here on this stuff Bodo so I'll defer to your
> better judgement. My belief in "peek" operations is that code should work
> exactly the same way whether you switch a bunch of peek operations in or
> out. Eg. a peek might be used optionally in an application to examine
> header bytes to determine where the data (which can then be read again
> *after* the peek) should be forwarded to. The risk is that if the peek()
> operation actually advances the SSL state machine and the code is working
> because of that side-effect, then switching that peek out (perhaps as an
> application option) might cause the state machine logic to dead lock
> somewhere, much to the bemusement of the application programmer (who
> should instead have it dead-locking every time because his code is wrong
> and just barely working because of an accidental side-effect).
But programs are not going to call SSL_peek() just because they don't
have anything better to do, are they? When SSL_peek() is called,
then usually because control flow depends on it; so SSL_peek()
cannot just be omitted without further changes to the program.
As far as unnoticed deadlocks are concerned, there are more likely
ways to obtain them; e.g. by selecting for readable data before trying
SSL_read() even if the previous error was SSL_ERROR_WANT_WRITE. Once
in a while the client cert chain sent during renegotiation might be
too long for your hosts TCP send buffer ...
--
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]
