Client behavior when server doesn't close connection?

[Michael Lazar]

On Thu, Jul 9, 2020 at 8:28 AM juhani <juhani at envs.net> wrote:
> Hi all,
>
> I'm juhani, new here, and implementing an Android gemini client.

Hi!

> While testing with live sites for the first time I found that some sites worked,
> and on others the response handling hung. Comparison of tcp streams revealed
> that on the working sites the last packet from the server had FIN flag, and on
> the failing sites it didn't.
>
> I changed the client so it doesn't try to read the whole response before parsing
> the header. And added timeout to make sure the connection is closed.

There is an open issue with jetforce where it was determined that the server
sends the TLS close_notify alert but doesn't ever close the TCP socket [1]. I
haven't had the time to figure out exactly what is going on yet though. I think
that either the server is waiting for the close_notify acknowledgement message
from the client which it never receives, or the server is not reacting to the
acknowledgement by shutting down the socket.

I do find it strange that it still appears to work with 90% of gemini client
implementations. I have found that if the client sends a close_notify for their
write stream after they transmit the request, then the server will close the
connection fully. The other possibility is that maybe your client isn't sending
the acknowledgement to the server?

My understanding of TLS is that it's not required for the server to wait for the
acknowledgement from the client, so ideally the server should be sending the
close_notify and then immediately closing the connection afterwards.

The main point that I want to make here is that this is a lot more nuanced than
waving it off as "just close the connection". The TLS connection needs to be
shut down safely to prevent truncation attacks, and to make things more
complicated the rules are different between TLS 1.2 and 1.3.

- mozz

[1] https://github.com/michael-lazar/jetforce/issues/32