On 5/5/06, Andrew Dennison <[EMAIL PROTECTED]> wrote:
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).
If you're trying to use the same SSL_SESSION, you're going to go into
an abbreviated reconnection unless you disable SSL session reuse.
If you've sent a closure alerts, after sending them the protocol
specifies that no more data can be sent in that direction. After
you've received a closure alert, SSL specifies that you close the
socket in that direction.
To force a renegotiation, SSL_renegotiate is appropriate -- it will
(from the server end) send out a server_hello packet, which causes the
client to send a client_hello packet, and the protocol starts anew --
even to the point of revalidating the certificates. This is all done
within the current encrypted streams.
SSL_clear() – prepare for next connection (* - see notes below)
- SSL_free is NOT issued in order to preserve session
information
If you preserve session information, you're going to get an
abbreviated negotiation, not a full one.
SSL_connect() issued – problem occurrence!
SSL_connect() returned (0); failed with error: SSL_ERROR_SYSCALL
errno : No error
WSAGetLastError: 0
ERR_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_READING
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:
The server must perform an SSL_accept() at this point, as the socket
descriptor it has is invalid. From this trace, it appears that the
server has performed a listen(), but it's on queue.
And that's it. I have no recourse but to remake the whole connection (TCP
layer included).
Don't call SSL_shutdown(). It's that simple. SSL_shutdown causes the
TCP layer to shutdown().
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?
It's possible to re-establish the SSL layer without affecting the
underlying connection. If you want to get rid of the current key
completely (though there's no practical reason for doing so, as it's
not used as a source of entropy) you can set SSL_cipher_list to +NULL,
SSL_renegotiate(), then to "STRONG", and SSL_renegotiate. Note that
the client must also have the NULL cipher suites enabled for this to
work -- otherwise, just call SSL_renegotiate and it'll work within the
current framework.
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?
You're calling SSL_shutdown. Don't. Call SSL_renegotiate with the
ciphers list, server cert, server key, and acceptable client cert CA
names in the SSL_CTX already reset to what you want to renegotiate
with.
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?
Then why are you trying to preserve the SSL_SESSION? A session
maintains key state and data, and allows for an abbreviated (i.e., not
full) handshake when a new SSL connection is created.
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.
Because the underlying TCP layer hasn't gotten an RST or FIN yet.
Once the FIN is received, the underlying TCP layer will return an
error on read, which leads to the SSL_ERROR_SYSCALL.
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
