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

Charles Mills charlesm at mcn.org
Fri Jan 11 20:27:24 UTC 2019

@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!




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 )











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.




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)) {

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)) {
                        slave_socket[x].ssl = 0; /* We are not in SSL mode
                    shutdown(slave_socket[x].fd, SHUT_RDWR);

                    ..... 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>

More information about the openssl-users mailing list