Warning for SSL_read()

[John Selbie]

I'm upgrading a socket server written for non-blocking TCP sockets to use OpenSSL in non-blocking mode.

In the man page for SSL_read, the following is stated:

"When an SSL_read() operation has to be repeated because of SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, it must be repeated with the same arguments."

There is no misunderstanding of that statement. It implies that the three parameters passed to this function (SSL, buffer, and length) must be the same each time.

But can there be an explanation for this?

I have a minor concern for converting many of the existing recv() calls to use SSL_read(). I can guarantee the length parameter is the same, but given the behavior of the code with regards to stack variables, it would be unsafe to assume that the buffer address is the same.

What would happen if after poll/select/epoll indicates new data, but the subsequent call to retry SSL_read passed in a different buffer address?  If the SSL function returns WANT_READ or WANT_WRITE, what is it doing under the hood to have to rely on identical parameters?

Why does the documentation for BIO_read not indicate a similar warning?

I'm also assuming it is save to have multiple SSL connection instances handled by the same thread - all using the same buffer for SSL_read (but never concurrently).  That would be my more likely workaround.

jrs

[Wim Lewis]

On 12 Aug 2013, at 3:36 AM, John Selbie wrote:
> I'm upgrading a socket server written for non-blocking TCP sockets to use OpenSSL in non-blocking mode.
>
> In the man page for SSL_read, the following is stated:
>
> "When an SSL_read() operation has to be repeated because of SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, it must be repeated with the same arguments."
>
> There is no misunderstanding of that statement. It implies that the three parameters passed to this function (SSL, buffer, and length) must be the same each time.
>
> But can there be an explanation for this?
>
> I have a minor concern for converting many of the existing recv() calls to use SSL_read(). I can guarantee the length parameter is the same, but given the behavior of the code with regards to stack variables, it would be unsafe to assume that the buffer address is the same.

I wonder if that warning is erroneously duplicated from the SSL_write() man page. From a glance at ssl3_read_bytes(), there's no reason that SSL_read() should care whether the read buffer is the same each time. SSL_write() can care, though.

As I understand it, SSL_write()'s semantics don't really follow write()'s semantics unless you set the SSL_MODE_ENABLE_PARTIAL_WRITE flag. The default behavior of SSL_write() is that you pass the same buffer+length repeatedly and SSL_write() will consume parts of that buffer (maintaining a partial write pointer internally) until it's done. (I much prefer the PARTIAL_WRITE semantics. :) ) So, if you're using the non-PARTIAL_WRITE semantics, then SSL_write() checks that the arguments are the same on a retry, as a way of checking that its internal partial-write pointer is still valid.

But SSL_read()'s semantics are read()-like whether you set that flag or not, and it doesn't look like it maintains any internal assumptions about the read buffer. All it does is memcpy() from the decryption buffer into the caller's buffer right before returning, as you'd expect it to.


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org