SSL_connect returns 0, with no error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL_connect returns 0, with no error

Andrew Dennison-2

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_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:

 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?

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

Reply | Threaded
Open this post in threaded view
|

RE: SSL_connect returns 0, with no error

Gayathri Sundar-2
-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Andrew Dennison
Sent: Friday, May 05, 2006 7:23 PM
To: [hidden email]
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_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:

 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

Reply | Threaded
Open this post in threaded view
|

Re: SSL_connect returns 0, with no error

Kyle Hamilton
In reply to this post by Andrew Dennison-2
On 5/5/06, Andrew Dennison <[hidden email]> 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                    [hidden email]
Automated List Manager                           [hidden email]