Never mind, I found this informative example of why the fcns have this kind of requirement to some extent:
http://openssl.6102.n7.nabble.com/SSL-MODE-ACCEPT-MOVING-WRITE-BUFFER-td6421.html "Here's the scenario again: 1) You try to write 16 bytes on a non-blocking SSL connection. 2) This results in a 24 byte record after encryption. 3) All but the last byte is sent, SSL gets "would block" when it tries to send the last byte. (TCP does not have a "send all or nothing" function. This can always happen no matter what OpenSSL says). 4) The other end will definitely get all the 16 bytes you wrote eventually (since they're almost completely sent), but it will not actually receive any of them until that last byte of the record is sent. Sending anything but that last byte breaks the SSL protocol. 5) OpenSSL cannot return '16' from SSL_write in this case because if it did, you would expect the other end to receive and process the 16 bytes you sent even if you don't call SSL_write or SSL_read again. (OpenSSL has no background service threads or anything. If you don't call into it, it will never send that last byte.) 6) Thus OpenSSL must return some number other than 16; however, if you do not realize that the other end will ultimately get the exact 16 bytes you just sent, things break. So what happens if the buffer changes in this case? If you think this cannot happen, please explain why. DS" The issue is that OpenSSL has already processed and is sending the 16 bytes (+ overhead) given to it but it also needs to tell the user that it needs to be called again when it is writeable to finish the write (as OpenSSL has no independent threat of control). The problem is that when write() returns -1/EAGAIN the user can safely assume that none of their data was taken and processed by the OS, but that is not true for SSL_write(). Regardless, it looks like if I enable the modes SSL_MODE_ENABLE_PARTIAL_WRITE | SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER, I will get what I need for my purposes. Cheers! ----- John Lane Schultz Spread Concepts LLC Cell: 443 838 2200 On Dec 3, 2014, at 2:03 AM, John Lane Schultz <jschu...@spreadconcepts.com> wrote: I’ve read that when SSL_read / SSL_write returns a SSL_ERROR_WANT_READ / SSL_ERROR_WANT_WRITE that when the required readable / writeable condition has been met that the call to SSL_read / SSL_write must be made with EXACTLY the same parameters as the previous call that returned the error. Can anyone explain why this requirement exists? I can understand how partially read / written cipher blocks could be annoying or similarly how an HMAC might cover lots of data and so the library being able to access the previously read / written user data could be helpful, but in both cases it seems like the library must keep whatever internal state is necessary to do the proper computations, considering that a user could call SSL_write a single byte at a time if they so chose and the library would still have to work. In my existing TCP code (that I’m now porting to use TLS), whenever a higher level write would block, I would make a copy of the remaining bytes to be written and throw it on a low level queue to be sent later, allowing the caller to not worry about coordinating memory management of their write buffers with my write function — kind of a send it and forget it functionality (until the low level queue fills up). This approach doesn’t work with OpenSSL because when a write blocks and I later call SSL_write again, it apparently requires the EXACT same parameters — meaning even the same pointers — even if the buffers that are pointed at contain the same unwritten data as previous calls. So, what am I missing? Why does this requirement exist? Cheers! ----- John Lane Schultz Spread Concepts LLC Cell: 443 838 2200 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
