On 17/11/2020 13:56, Michael Wojcik wrote: >> From: Kyle Hamilton <aerowolf@xxxxxxxxx> >> Sent: Tuesday, 17 November, 2020 02:37 >> On Fri, Nov 13, 2020 at 11:51 AM Michael Wojcik >> <Michael.Wojcik@xxxxxxxxxxxxxx> wrote: >>> >>>> From: Brice André <brice@xxxxxxxxxxxxxxxx> >>>> 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. Just for clarity, there is no such function as SSL_close. I assume SSL_shutdown is what people mean. Matt