On Thu, Jul 31, 2008 at 01:02:16PM -0700, David Schwartz wrote:
>
> > Let me trace through the application. Looking at the source code, it
> > appears that the application may have a bug (checking the SSL error stack
> > via SSL_get_error() when SSL_read() returned > 0) but that what
> > is actually
> > happening here is:
> >
> > 1) SSL_read() is returning < 0, SSL_get_error() is returning WANT_READ
> >
> > *but*
> >
> > 2) Internally, SSL_read has taken the bytes from the socket buffer, so
> > calling select() on the fd for read will still never work. There seems
> > to be no way for the application to know that what it *really* needs to
> > do is retry the call with a larger buffer, that nothing else
> > will suffice.
>
> If this is really what's happening, it's a bug in OpenSSL. The application
> should be able to pass a 1-byte buffer the OpenSSL and get 1 byte of
> decrypted data.
Consider that when running with the current non-blocking API, once OpenSSL
takes the data out of the socket buffer, both library and application
programmer are basically stuck. The socket will never come up selectable
for read again, but there is no other way for the application to find out
that there is further data pending internally in OpenSSL.
If the intended semantics are "select, then loop reading until WANT_READ
is returned", this is:
A) Another significant difference between how read(2) and
SSL_read() operate for nonblocking sockets. Basically all
these differences cause problems. If SSL_select() or SSL_poll()
were provided, it could address this by looking at the internal
buffering; but I think we've argued about the advisability of
providing SSL_select() in the past.
B) Still problematic even if code is adapted to this API, because
you can't use the arrival of data at the socket to enforce
fairness between peers. Or, rather, you probably can, but only
at the expense of looping over all sockets you haven't yet
seen WANT_READ on -- in the worst case (the case where the peer
writes exactly the application's read buffer size) this at least
doubles the number of calls to SSL_read() for a given workload.
Thor
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
