I am currently experiencing an issue using SSL_connect() on a non-blocking socket.
I have set SSL_MODE_AUTO_RETRY so that it would not return right away, and as a backup measure have included handling for SSL_WANT_READ/SSL_WANT_WRITE such that the entire connection process is handled in it's own thread that will only exit once a connection has been made (or the main thread timeout for that thread expires, but that is set for 5 minutes).
The issue arises on the second connection attempt after having already established a successful connection. What I am attempting to do is to shutdown the SSL layer and perform a full handshake to re-establish a new SSL connection without affecting the underlying TCP socket (whose connection I hope to maintain throughout this process).
The sequence of commands is more or less this:
SSL_connect()
[connection established, all is well]
[time passes, data is sent/received]
Read and write threads are suspended pending session re-establishment
- connection shutdown
SSL_clear() – prepare for next connection (* - see notes below)
- SSL_free is NOT issued in order to preserve session information
WSAGetLastError: 0
ERR_error_string - 0 - error:00000000:lib(0):func(0):reason(0)
SSL_state_string_long(): SSLv3 read server hello A
At this point, I have tried both to issue SSL_connect again, or to issue the requested SSL_read()** first (which succeeds), and then to issue SSL_connect again. Both result in the following:
SSL_connect() returned (-1); failed with error: SSL_ERROR_SYSCALL
errno : No error
WSAGetLastError: 10053 - WSAECONNABORTED
ERR_error_string - 0 - error:00000000:lib(0):func(0):reason(0)
SSL_state_string_long(): SSLv3 read server hello A
And that's it. I have no recourse but to remake the whole connection (TCP layer included).
Notes:
My questions are these:
1) Is what I am attempting even possible? Is it possible to re-establish the SSL layer without affecting the underlying connection?
2) If it is possible to do this, where am I going wrong, how might I correct it, or should it be done in some different way?
3) I am aware of and have also used SSL_renegotiate in a different situation. The intent here is for a full handshake to occur for security purposes. Renegotiation (via SSL_renegotiate) is used in this application in another circumstance, but it is unclear whether this fully re-establishes the communications security for this link. Is it any less secure than the negotiations that occur during connection?
4) Regardless of the legitimacy of this method for re-establishment of the SSL connection, why does SSL_connect() return 0 with no useful error information as to what should be done to correct the problem. It doesn't even report SSL_WANT_READ in it's return, though SSL_want() is quite ready to return with SSL_READING, a condition where (according to the docs) a call to SSL_get_error() should result in SSL_WANT_READ, not SSL_ERROR_SYSCALL. This would seem to be somewhat contradictory.
If someone could shed some light on some or all of these questions, I would appreciate it.
Andrew Dennison
