Susan, The problem below is reported against 7.1.4. As background, we believe that the “lingering connections” situation described below is either causing or contributing to the number of connections on the server to increase. We see that nearby 6.2.1 nodes under similar load would see a smaller increase in the number of connections compared to 7.1.4. Is it possible that changes between 6.2.1 and 7.1.4 may have an effect such as the tuning done towards calling SSL_shutdown() in commit 0ab449? Appreciate any insights.
Thanks, Peter From: Susan Hinrichs [mailto:[email protected]] Sent: Saturday, September 01, 2018 3:57 PM To: [email protected] Subject: Re: ATS and TLS close-notify Yes, ATS should respond with close notify or at least FIN the connection. What version of ATS are you seeing this with? If there was already an application data packet in flight, it may arrive after the client sends the close notify. But in general ATS should shut down the connection. On Fri, Aug 31, 2018, 11:31 PM Jeremy Payne <[email protected]<mailto:[email protected]>> wrote: Context: Openssl 102k ATS 714 I notice that at times a client will send a TLS 1.2 close-notify, immediately followed by a FIN-ACK. Which seems to be following spec. "It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection." However, in response, ATS continuous to send 'application data' instead of issuing its own TLS 1.2 close-notify. Which then results in connections lingering waiting for an ACK back from the client. Which will never come, since per spec: "Any data received after a closure alert is ignored." Is ATS still within TLS 1.2 spec by continuing to send application data, even though the client sent a close notify ? I tested some other https servers compiled against openssl 102k, and I see a close notify sent by the client, with the https server responding with it's own close notify. Thanks!
