Wireshark trace file RST after FIN packet

Question

I have a client and Application server, that exchange certificates with each other and establishes a secure TLS connection.

At the end of such connection, after application data is transferred. The client sends a FIN packet to the server, in return the server replies with a TLSV1.2 encrypted alert packet.

This is further ack by the client and the client this time sends an RST packet. Could you help me decipher this behaviour. I am trying to baseline my traffic between these endpoints and later take these notes as input.

From this link here, https://serverfault.com/questions/854692/client-sends-rst-after-fin-ack it looks like the socket is not shut down before it is closed, which comes down to bad programming. I am curious to confirm whether this is the case.

Answer 1

According to The TCP Guide on terminations, the usual order of events is:

1. ---> FIN
2. <--- ACK
3. <--- Waits for the application with the socket to ACK the connection-close
4. <--- FIN
5. ---> ACK

Steps 2 and 3 are often done at the same time, for a FIN/ACK packet. A nice, stately dance.

However, TCP has another way to tear down a connection, and it's faster than this stately procedure. Throw an RST packet at it. It's a rude way to do it, but HTTP can get away with it since data-transfer has two flows and if the second flow is done (the server response) the whole thing is done. For HTTP connections which are notoriously slow (which is to say, have a foot-tapping human often waiting for a page to render while the browser deals with 50+ asset requests), little speed tweaks are how anything gets done on time.

In this case, the 185 host is trying to be nice about it, but the 172 host is all I'm done, go away.

As a network security administrator the prevalence of RST packets in flows like these stands out as network anomalies. This is one area where protocols are being abused in the name of optimization. It's an expected flow for HTTP traffic these days.