At 11:14 18.07.2006 +0100, you wrote:

>
>
>I'm a little interested in the three_byte_header situation you raised.
>If I understand the outline correctly you were questioning whether it is
>safe to mix calls of SSL_read() and SSL_write() because when you looked
>over the SSL library code you saw a variable that both the read
>machinery and write machinery were sharing.  You then thought it maybe
>possible for the machinery to get confused.
>
>I believe its 100% safe to mix calls to SSL_read()/SSL_write() in any
>order upon a valid SSL* handle from the same thread of execution.  

Indeed we have two threads (one for write and one for read). But the SSL*
handle is protected by a mutex with really large granularity: if a thread
wakes up it takes the lock and does the things he has to do including ssl
connection handling. After it has finished all the work it releases the
lock. So there should be no problem.

>If
>you have identified a problem that makes that claim untrue then that
>smells like a bug.
>
>So is the three_byte_header thing a misunderstanding of the source or a
>genuine concern ?
>

Now it looks like a library bug to me. If I understand the sources
correctly SSL_read works as follows:

1)If there is any decrypted data in the internal buffer SSL_read simply
returns this data. 
2)Only if this internal buffer is empty new (encrypted) data is read from
somewhere (BIO/fd - I don't know). 
3)From this data a short header is decoded and the results are stored in
some variables (three_byte_header, padding, ...) in the SSL* handle. 
4)Then some sort of payload data length is calculated using three_byte_header. 
5)Then SSL_read tries again to read these amount of data from somewhere. 
    5a)If this read operation fails it returns. The comment at this point
in the source is /* ERROR */ but it may normally happen if not enough data
is available at this time. 

If SSL_read returns in 5a) then next time SSL_read is called it immediatly
starts with step 4) simply using the current value of three_byte_header
which may be modified in a call to SSL_write.

I see two ways to prevent this behavior:

a) Our application has to provide "enough" data so that SSL_read never
falls into step 5a. That means it has to introduce an additional header on
top of the ssl data stream or it has to decode the ssl header itself like
SSL_read in step 3. 

b) Change the library in the following way: replace three_byte_header with
wthree_byte_header (used by SSL_write only) and rthree_byte_header (used by
SSL_read only). I have tested this and with this change our application
runs without problems (and without the hack I described in my first email). 

Solution a) looks strange to me and my understanding of the
BIO_write/SSL_read functionality is that it should be possible to BIO_write
any amount of data, even a single byte should be possible.

So I would prefer b) (also because we do not need to change our
applicationin in that case :-). But I'm not sure about the side effects of
this change. Maybe I should post the question to the dev-maling list.


Henrik

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to