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

[Charles Mills]

>        SSL_shutdown(connection) || SSL_shutdown(connection);

I like it! (Not!)

I don't pretend to be a bits and bytes expert on TCP protocol. You can't be
an expert on everything.

So I will listen to expert advice. I know 99% of you all are 'nix guys and
this is a Windows problem. I am seeing OTOH where my Windows doc says
closesocket() does an abortive termination, and OTOH a discussion of a
graceful closesocket() with SO_LINGER/SO_DONTLINGER.

(1) This code is (at the application level) purely a receiver of data and
(2) without the TLS layer in place it is hard to picture any meaningful data
transfer and (3) we are in a session cleanup situation anyway -- so it seems
to me that an abortive disconnect is perfectly fine. Am I wrong?

Thanks for all of your help.

Charles


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Michael Wojcik
Sent: Friday, January 11, 2019 12:48 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Close TCP socket after SSL_clear()?

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
Of Karl Denninger
> Sent: Friday, January 11, 2019 13:04

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

Or if you really want to baffle future maintainers:

        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.
> ...
>                    shutdown(slave_socket[x].fd, SHUT_RDWR);
>                    close(slave_socket[x].fd);

Maybe I'm missing something, but I don't see much advantage to calling
shutdown(SHUT_RDRW) and then immediately calling close(). close will
implicitly do what shutdown does, in the normal case, including trying to
send unsent data and waiting (for a while) for any remaining ACKs.

If there's unsent or un-ACK'd data, shutdown will attempt to send it until
the TCP retransmit limit is reached; that's normally longer than the linger
time for the socket, so shutdown could try harder, and by the same token
block longer, than close. But the same effect can be achieved by setting a
longer linger time for the socket and just calling close.

Similarly, if linger has been disabled (by setting the SO_LINGER option
appropriately), then close will just abort the connection (i.e. send an RST,
rather than a FIN, and not wait for the corresponding FIN-ACK; or if the
peer sent the FIN, send an RST rather than a FIN-ACK and not wait for the
last ACK). But anyone who disables linger on a TLS connection gets what they
deserve.

shutdown is generally useful if:

- You only want a half-close (which is rarely used, even when it would be
useful, and isn't generally appropriate for a TLS connection).

- You want a full close, but you want to be able to retrieve the error
information from the socket if the close fails. In that case, use shutdown,
followed by getsockopt(SO_ERROR) if shutdown returns an error, followed by
close. But your code is ignoring the return value from shutdown and not
using getsockopt(SO_ERROR).

The real question is: will the application do anything differently if any
remaining outbound data - which there shouldn't be because at this point
we've tried to do a blocking SSL_shutdown - can't be sent, and the closing
FIN / FIN-ACK / ACK handshake completed, within the default linger time? And
if so, will the application do anything that can't be achieved by just
increasing the linger time?

I think it'd be nice if more non-trivial applications used
shutdown(SHUT_RDWR) + getsockopt(SO_ERROR) + close, and reported the error
(if there is one) for diagnostic purposes. But beyond that there isn't a lot
most applications can do, and for most a simple close is probably going to
be fine.

But as I said I may have overlooked some good reason for this particular
code pattern.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users