Kyle Hamilton wrote:
If SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE are returned, the
arguments *must* be *exactly* the same. This includes the data
pointed to by the buffer. There is a way to set a mode on the SSL
connection to allow a moving buffer, but that's it. SSL will not
buffer the data passed to it.
And if you grep the source tree for that mode, you will see it doesn't
do anything. The flag being refered to is
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER from ssl.h for SSL_set_mode() call.
It is like a flag that:
* Either served a purpose long ago but not anymore and nobody took it out.
* A flag that has been put in place to attempt to ensure all OpenSSL
users/applications that wish to work this way set the flag. So that
some future change to OpenSSL can be made internally.
At this moment in time the documentation around SSL_write() and the flag
simply causes user confusion like this. I think it would be true to say
all of the following:
* It does not matter if you set the flag or not, OpenSSL as a library
does not change its behavior in anyway.
* No one is actively working on developing the OpenSSL library itself
to a) do anything with the flag, b) to change the way the library works
under the bonnet so that the flag becomes a requirement.
* At this moment in time your repeated SSL_write() call must simply
supply AT LEAST the SAME data (as in CONTENT and LENGTH) again. The
actual virtual address of the buffer passed CAN be changed. The length
if the data CAN be changed so long as it is the same length or longer
during the 2nd call. What you can not do is shrink the data length or
change the contents otherwise unpredictable results can occur in your
decrypted plaintext stream at the remote end.
* It is advisable that ALL users who are unsure of the documentation
standpoint simply set the flag and be done with it. This means that
OpenSSL will clearly return error codes so your application fails-fast
in a reliable and predictable way should someone actually do something
with the flag in the future and you upgrade your OpenSSL library version.
If SSL_write returns SSL_ERROR_WANT_READ, then just call SSL_write
again. (Usually, in this case, you can select() on the underlying
socket to determine if there's any pending data to be read from the
socket.) If SSL_read returns SSL_ERROR_WANT_WRITE, just call SSL_read
again. (You might try to select() to see if the socket is writable.)
What Kyle is saying is that YES an SSL_write() can cause a read() system
call to be made on the socket. So you select() for read, when that
becomes available you can issue your SSL_write() with your data again to
clear it.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
