From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Andrew Dennison
Sent: Friday, May 05, 2006 7:23 PM
To: openssl-users@openssl.org
Subject: SSL_connect returns 0, with no error
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()
- SSL_WANT_READ/SSL_WANT_WRITE- SSL_state_string_long(): SSLv3 read server hello A- SSL_WANT_READ/SSL_WANT_WRITE- SSL_state_string_long(): SSLv3 read finished A
[connection established, all is well]
[time passes, data is sent/received]
Read and write threads are suspended pending session re-establishment
SSL_shutdown() – close-notify sent (OK)SSL_shutdown() – host close-notify received (OK)- connection shutdown
SSL_clear() – prepare for next connection (* - see notes below)
- SSL_free is NOT issued in order to preserve session information
SSL_connect() issued – problem occurrence!SSL_connect() returned (0); failed with error: SSL_ERROR_SYSCALLerrno : No errorWSAGetLastError: 0ERR_error_string - 0 - error:00000000:lib(0):func(0):reason(0)
SSL_state_string_long(): SSLv3 read server hello A
An additional call to SSL_want() at this time returns: SSL_READINGAt 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:
* Even If this SSL_clear is not issued, the same thing happens.** If two SSL_read()s are issued in succession, the connection will return WSAECONNABORTED as well.
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?
AFAIK, once closure alerts are sent, the TCP connection cannot be reused by another SSL connection. Am not sure if SSL as such supports this scenerio of reusing a TCP connection across multiple Client Hello Pkts. Renegotiation can happen, but the TCP fd cannot be re-used..for a new handshake. SSL_ERR_SYSCALL seems to happen coz the fd is invalidated and you cant send/recv on that anymore. .
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?
I could be wrong, but this is not possible.
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?
I think your asking abt the "hello request", which triggers a new handshake on the same fd over which you had already a SSL connection established. Now the thing is the SESSION is reused as such for subsequent connections between peers, so that the handshake time is reduced, doing a complete negotiation of security params on a per connection basis, is only a performance overhead, but ofcourse more secure (debatable), but otherwise only the change cipher spec messages are exchanged and the master secret is reused. Not sure if you really want to negotiatie a new master secret for every TCP connect..but all depends on your requirement.
You can disable SSL SESSION reuse, which will trigger ssl handshakes from scratch on a per connection basis, but once again u need to do a TCP accept before doing an SSL Accept, the fd cannot be reused, you can treat it inline with IKE phase-1 and IKE phase-2 rekey..
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
