Bodo Moeller wrote:
>
> Function ssl2_read, formerly known as SSL2_read and (via a #define in
> 0.6.6b) also as SSL_read, in file ssl/s2_pkt.c contains the following
> confusing code and comment:
>
> /* If a 0 byte packet was sent, return 0, otherwise
> * we play havoc with people using select with
> * blocking sockets. Let them handle a packet at a time,
> * they should really be using non-blocking sockets. */
> if (s->s2->ract_data_length == 0)
> return(0);
> return(ssl2_read(s,buf,len));
>
> I believe that this is now wrong, and alreay was wrong in 0.6.6b. Any
> SSL_read or SSL_write can block even if select() signalled readability
> or writeability -- the select() result means only that progress is
> guaranteed, but not that the SSL_read or SSL_write will complete in
> one call: For every SSL_read or SSL_write, the application program has
> to expect several OS level reads and writes (in both directions as a
> handshake can be started at any time), and if you really want to avoid
> blocks, you must use non-blocking I/O. So I think what we should
> really do is ignore the empty block and do a "goto" to the start of
> the function (a recursive call to the function would be bad because if
> someone has the bad luck to have to use a compiler that does not
> recognize end recursion, an attacker can fill the stack).
> Am I right?
Well, using a while() or do...while() would be far more elegant than
using a goto, but apart from that it sounds right.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]