Sorry to come at this thread a week later.
I can see both sides of the problem here, there are infact three distinct modes of operation:
Non-Blocking: There is where the underlying socket descriptor is in non-blocking mode. SSL API calls return -1 and set SSL_get_errno() to allow for EAGAIN or ERROR to be handled. Everybody agreed in the thread on this behavior.
Blocking (with SSL_MODE_AUTO_RETRY): This is where OpenSSL can use as many blocking read() call as it wants in order complete application level data processing with the transport layer.
Blocking (without SSL_MODE_AUTO_RETRY): This is the default mode for blocking socket, if I understand the comments correctly. In this mode only one blocking read() system call is allowed by the SSL library, if that block thats ok, if it doesn't block and returns data the SSL API call must return control back to applicaton or if the SSL library still wants to call read() for more data another time it _MUST_ do so in a non-blocking fashion.
All 3 modes have valid use cases when you have a layer between transport and application. It is not correct to be talking about blocking transport layer API and blocking SSL layer API as being interchangable; these 3 modes cater for every usage case. Two of the modes are direct equivalents to the transport layer blocking/nonblocking modes, the third deals with the disparity of the extra SSL layer in a elegant way.
The problem this thread is covering is the "Blocking (without SSL_MODE_AUTO_RETRY)" case:
If I understand correctly the original thread poster was explaining a bug in using OpenSSL s_client triggered during a renegotiation (was this client or server initiated? SGC related?). It is unclear to me if Marek thinks this problem is due to a library bug or simply that s_client should be clearing SSL_MODE_AUTO_RETRY in its block socket use case for that program. We all know that OpenSSL s_client has a command line option to enable nonblocking mode so the discussion about we should be using non-blocking is bogus in this situation, maybe this should be the default for s_client anyway.
If its a library bug I believe Marek is saying it is wrong that OpenSSL should be re-issuing a read() blocking system call for a 2nd time (within the same SSL_xxxx() API call) when SSL_MODE_AUTO_RETRY is not set. It should return -1 and WANT_READ to the application layer. If OpenSSL really wants to for a 2nd time make a read() system call it should use poll/select on the transport layer or temporarily mark the socket non-blocking to guard against a blocking system call before. This is because the application never authorized it to use more than one blocking system call because SSL_MODE_AUTO_RETRY is not set.
Marek is correct in that system calls return EINTR and other returns which are valid non-fatal-error returns to blocking calls, the handling of writes simply allow a partial write to occur in the SSL API, so a -1 return to a blocking SSL API call is valid too. I also agree that if Marek's finding is true it should not break any existing applications that are correctly written, that is when an SSL API call returns -1 you find out why with SSL_get_errno() and deal with the situation appropriately.
Maybe both parties could point out the errors in the summary above. Everyone seems to be correct in their comments but I'm not sure they are seeing the same view of the problem as I did when reading the thread.
Darryl ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
