[openssl-users] Close TCP socket after SSL_clear()?

[Charles Mills]

@Karl, thanks, I'm not sure of anything. This was my first OpenSSL project
and I just hacked on it until it "worked." It's been working for years but
now we are seeing a re-connection error.

 

So, it sounds like

 

.         Do the SSL_shutdown() a second time if it returns 0.

.         Lose the SSL_clear()

.         There is an SSL_free() in there following the snippet I pasted -
leave it in there

.         Clean up the underlying socket appropriately. Looks like perhaps
shutdown(socket, SD_BOTH) is the Windows equivalent of SHUT_RDWR - followed
by closesocket()

 

Thanks again!

 

Charles

 

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Karl Denninger
Sent: Friday, January 11, 2019 10:04 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Close TCP socket after SSL_clear()?

 

 

On 1/10/2019 17:07, Charles Mills wrote:

On Windows, for a new session, I am issuing a Windows accept() followed by
SSL_new(), SSL_set_fd() and so forth.

 

When the session sees some sort of an abnormal receive condition, I am doing

 

       int retCode = SSL_get_shutdown(sessionSSL);

       if ( retCode & SSL_RECEIVED_SHUTDOWN )

       {

              SSL_shutdown(sessionSSL);

       }

       else

       {

              SSL_clear(sessionSSL);

       }

 

Questions:

 

1.       Do I also need to do a closesocket() (equivalent to UNIX close())
on the Windows socket?

2.       Does anyone want to critique the above logic in any other way?

 

The code basically "works" but I see evidence that a Windows TCP session is
still open following an SSL error.

 

Thanks,

 

Charles Mills




 

Are you sure you want to use SSL_clear() in the first place?  It retains the
session's settings which is only useful if the *exact* same peer is going to
reconnect on the same SSL object.  If a *different* peer connects there's a
decent shot that the connection will fail.

You also likely want to call SSL_shutdown(connection) again IF the first
call returns zero; the first one sends a notification and if the other end
hasn't closed yet returns zero.  The second waits for a termination, either
normal notification or abnormal, from the other end.

    if (!SSL_shutdown(connection)) {
        SSL_shutdown(connection)
    }

The underlying handle is still open at the OS level after this, so on Unix
anyway you want to notify the OS that the socket is invalid for further I/O
and then close it.

Code snippet (took_error is a flag that says "this connection is no longer
needed", it's could be either an error in the higher level code or a "we're
all done, let this connection go" indication):

                if (slave_socket[x].took_error) {
                    slave_socket[x].connected = 0;  /* Connection is void */
                    if (slave_socket[x].ssl_fd != NULL) { /* If there's a
valid SSL connection */
                        if (!SSL_shutdown(slave_socket[x].ssl_fd)) {
                            SSL_shutdown(slave_socket[x].ssl_fd);
                        }
                        SSL_free(slave_socket[x].ssl_fd);
                        slave_socket[x].ssl = 0; /* We are not in SSL mode
*/
                    }
                    shutdown(slave_socket[x].fd, SHUT_RDWR);
                    close(slave_socket[x].fd);

                    ..... Clean up the rest of the things you need to do
when the connection ends

Since the next connection may come from a different peer I do not use
SSL_clear but rather SSL_free.

The call to shutdown() tells the OS to send any data queued on the socket,
wait for an ACK and then send FIN.

-- 
Karl Denninger
karl at denninger.net
The Market Ticker
[S/MIME encrypted email preferred] 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190111/2c5dad1e/attachment-0001.html>