> 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?).
- client sends some data - server initiates renegotiation and immediately after that sends some data back to the client > 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. Well, if s_client is broken in the blocking mode maybe it should be removed completely. I did test it in the non-blocking mode and, of course, it does not have the described error. > 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. I think you summary is correct. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
