(This is a resubmit of the same post with the numbered list represented better here in text format, as the previous mail got the numbered list presented well only in the HTML version.) Dear OpenSSL list, I need your authoritative answer on the following question. Guaranteedly, this same question has been voiced on this mailing list already, in less or more similar wording. My question is: Please help me to get clear on *exactly* what my program needs to do in response to a SSL_WANTS_READ or SSL_WANTS_WRITE return value, from either of SSL_read, SSL_write and SSL_shutdown. This is for use of OpenSSL in the Nonblocking IO mode on a socket. I will also use the BIO mode later, so let's include this in the question too; The reason I ask, is that if my understanding of how this should be handled is not *ABSOLUTELY CORRECT*, then because of my incorrect understanding I will be at risk of implementing the select() calls in my program incorrectly, and that would lead to risk of either *INFINITE LOOP* or *ZOMBIFICATION* (because of doing a select() too little or too much), which would be *ABOUT AS BAD AS A PROGRAM BUG COULD EVER BE*. I humbly ask you to help me get clear on this, simply by confirming to me that the understanding expressed in each the following points is *ABSOLUTELY CORRECT*. With your clear confirmation that each of these points are indeed correct, perhaps maybe the last word needed to be voiced on this topic will have been said - thank you very much!! The points that I kindly ask you to confirm that they are absolutely correct are: ## 1 By giving me an SSL_WANTS_READ return value to an SSL_read call, OpenSSL tells me that it cannot do any more SSL_read work for me i.e. any more reading from the SSL channel for me, without that I re-invoke SSL_read, *and before that re-invocation* performed a select() for *readability* on this socket (so that is, include this socket in the *readfds* argument to the select() call) as to get a confirmation that more data has arrived on this socket and then having acquired this confirmation. ## 2 By giving me an SSL_WANTS_READ return value to an SSL_write call, OpenSSL tells me that it cannot do any more SSL_write work for me i.e. any more writing to the SSL channel for me, without that I re-invoke SSL_write, *and before that re-invocation* performed a select() for *readability* on this socket (so that is, include this socket in the *readfds* argument to the select() call) as to get a confirmation that more data has arrived on this socket and then having acquired this confirmation. ## 3 By giving me an SSL_WANTS_READ return value to an SSL_shutdown call, OpenSSL tells me that it cannot do any more SSL_shutdown work for me i.e. any more pushing forward of the clean closure of the SSL channel for me, without that I re-invoke SSL_shutdown, *and before that re-invocation* performed a select() for *readability* on this socket (so that is, include this socket in the *readfds* argument to the select() call) as to get a confirmation that more data has arrived on this socket and then having acquired this confirmation. ## 4 Thus in all points 1)-3), SSL_WANTS_READ is essentially OpenSSL's way to say that it ran out of input data on the socket, and that it needs more input data in order to proceed with the respective operation at hand. ## 5 By giving me an SSL_WANTS_WRITE return value to an SSL_read call, OpenSSL tells me that it cannot do any more SSL_read work for me i.e. any more reading from the SSL channel for me, without that I re-invoke SSL_read, *and before that re-invocation* performed a select() for *writability* on this socket (so that is, include this socket in the *writefds* argument to the select() call) as to get a confirmation that the next SSL_read call performed will be able to write more data to the socket, than the SSL_read call that returned SSL_WANTS_WRITE could. ## 6 By giving me an SSL_WANTS_WRITE return value to an SSL_write call, OpenSSL tells me that it cannot do any more SSL_write work for me i.e. any more writing to the SSL channel for me, without that I re-invoke SSL_write, *and before that re-invocation* performed a select() for *writability* on this socket (so that is, include this socket in the *writefds* argument to the select() call) as to get a confirmation that the next SSL_write call performed will be able to write more data to the socket, than the SSL_write call that returned SSL_WANTS_WRITE could. ## 7 By giving me an SSL_WANTS_WRITE return value to an SSL_shutdown call, OpenSSL tells me that it cannot do any more SSL_shutdown work for me i.e. any more pushing forward of the clean closure of the SSL channel for me, without that I re-invoke SSL_shutdown, *and before that re-invocation* performed a select() for *writability* on this socket (so that is, include this socket in the *writefds* argument to the select() call) as to get a confirmation that the next SSL_shutdown call performed will be able to write more data to the socket, than the SSL_shutdown call that returned SSL_WANTS_WRITE could. ## 8 Thus in all points 5)-7), SSL_WANTS_WRITE is essentially OpenSSL's way to say that the OS' write buffer filled out so that OpenSSL's call to fwrite() for the socket, wouldn't accept any more data written to the socket at the time, and that for this reason it needs/wants separate ascertainment that the socket is now writable i.e. an fwrite() to the socket will accept at least one more byte of data written to it. ## 9 Beyond the SSL_read and SSL_write calls mentioned specifically to be done in points 1)-3) and 5)-7) (and if mentioned only), my program is *not needed or otherwise indicated perform any more SSL_read and SSL_write calls whatsoever, at any point*. ## 10 One consequence of all of the above 1)-9) is that, if I would want to implement a flexible SSL channel reading procedure in my program, and i implement it in terms of SSL_read() and select() only, and the point with my procedure is to provide a facility for reading from an SSL channel in such a way that * A certain number of bytes are required to be read before it returns, and the procedure should block until it gets that many bytes (let's call these "bytes_needed"), and * A certain number of bytes are allowed to be read before it returns just in case they would happen to be available for reading already at the time of the call, but there will be no blocking to get that many bytes (let's call these "bytes_optional"). So, this procedure would be defined something like: my_flexible_reading_procedure(SSL* ssl,int socket,void* buffer,int bytes_needed,int bytes_optional). Then, my program invokes this procedure, for needing 1 byte and optionally accepting another 999. my_flexible_reading_procedure invokes SSL_read(), which returns SSL_WANTS_READ. my_flexible_reading_procedure select():s for readability and eventually the select() tells us that more input data is available. my_flexible_reading_procedure then invokes SSL_read() again, and it tells us it read 5 bytes. my_flexible_reading_procedure has now gotten all bytes it needed (which was 1), but, it *must assume* that the reason that SSL_read() returned with only 5 bytes instead of all the 1 + 999 = 1000 bytes, was because of technicalities regarding buffering or whatever, so my_flexible_reading_procedure must reinvoke SSL_read(): my_flexible_reading_procedure invokes SSL_read() again, and this time it returns SSL_WANTS_READ. Now, thanks to the clarifications above, we know that a SSL_WANTS_READ return value just means that OpenSSL has read all input data available from the socket at this time, and that my_flexible_reading_procedure want to read/get any more SSL channel data then it at first needs to wait for more data to come in on the socket from the other party, by making another select() for readability. my_flexible_reading_procedure doesn't want this though, because it already got all the bytes it needed, which was 1. So therefore, my_flexible_reading_procedure returns with a success result, reporting that it got 5 bytes, and we know that the SSL channel is in a healthy state, and my program is free to make another SSL_read, SSL_write or SSL_shutdown call at any moment it wishes to, and then of course if that respective call would return SSL_WANTS_READ or SSL_WANTS_WRITE in turn, then that will need to be handled as described in 1)-3) and 5)-7) above. 11) This means that libCurl's handling of SSL_ERROR_WANT_READ result, and SSL_ERROR_WANT_WRITE result too right?, from SSL_read, defined on rows 1000-1007 and 3079-3083 in https://github.com/bagder/curl/blob/aba2c4dca2601cb942f47ea9622e01001c01b799/lib/vtls/openssl.c , and its handling of SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE results from SSL_write, defined on rows 3025-3031, is *absolutely broken* right? (Perhaps libCurl's use of OpenSSL is done in some limited scope and context so that somehow doing it like this works, but generally speaking, implementing it like this is *absolutely broken*.) ## 12 Nginx' handling of SSL_WANT_READ&_WRITE result from SSL_read and SSL_write is correct though, https://github.com/git-mirror/nginx/blob/76c07f20962badcadaa0e01d0d8be73cc9ed461f/src/event/ngx_event_openssl.c : SSL_WANT_READ is channelized to a select() for more input data (that's on rows 803 and 1318), and SSL_WANT_WRITE is channelized to a select() for writability (that's on rows 819 and 1061). (Presuming that what "c->read->ready = 0;" really does is to trig a select() for more input data, and what "c->write->ready = 0;" really does is to trig a select() for writability.) Thank you very much for taking your time to clarify this matter! Mikael
