Server application hangs on SS_read, even when client disconnects

[Michael Wojcik]

> From: Kyle Hamilton <aerowolf at gmail.com>
> Sent: Tuesday, 17 November, 2020 02:37
> On Fri, Nov 13, 2020 at 11:51 AM Michael Wojcik
> <Michael.Wojcik at microfocus.com> wrote:
> >
> > > From: Brice André <brice at famille-andre.be>
> > > Sent: Friday, 13 November, 2020 09:13
> >
> > > "Does the server parent process close its copy of the conversation socket?"
> > > I checked in my code, but it seems that no. Is it needed?
> >
> > You'll want to do it, for a few reasons: ...
>
> There's another reason why you'll want to close your socket with
> SSL_close(): SSL (and TLS) view a prematurely-closed stream as an
> exceptional condition to be reported to the application. This is to
> prevent truncation attacks against the data communication layer.
> While your application may not need that level of protection, it helps
> to keep the state of your application in lockstep with the state of
> the TLS protocol.  If your application doesn't expect to send any more
> data, SSL_close() sends another record across the TCP connection to
> tell the remote side that it should not keep the descriptor open.

This is true, but not what we're talking about here. When the
application is done with the conversation, it should use SSL_close
to terminate the conversation.

Here, though, we're talking about the server parent process closing
its descriptor for the socket after forking the child process. At that
point the application is not done with the conversation, and calling
SSL_close in the server would be a mistake.

Now, if the server is unable to start a child process (e.g. fork fails
because the user's process limit has been reached), or if for whatever
other reason it decides to terminate the conversation without further
processing, SSL_close would be appropriate.

--
Michael Wojcik