I'm seeing RST+ACK received at a PC, often, and it is not a response to a SYN sent to a closed port. In one case, the PC opened a TCP session, sent HTTP 1.1 traffic in a TLS session, got a response, ACKed the response. The connection sat idle for 130 seconds and then the host sent RST+ACK. In another case, the server sends data in a TLS session, the PC ACKs it, and then the PC sends FIN+ACK. The server responds with RST+ACK. If the server were unhappy with the TCP session, I'd expect RST without ACK. It appears to be using RST+ACK instead of FIN+ACK. There are firewalls/load-balancer between the PC and the server. This doesn't look like a half-open session. What would cause RST+ACK in the absence of an attempt to connect to a closed port? asked 20 Mar '12, 13:31  Kleinfelter |
One Answer:
Seeing TCP/RST packets in SSL traffic is not uncommon. While "the world shouldn't be like that", fact is that Microsoft Internet Explorer used to be not-so-great in handling persistent SSL sessions, so webservers started to use the "unclean-shutdown" option to not frustrate the MS-IE users (instead of making sure MS solved the bug in their browser. The unclean shutdown meant to no use the SSL CloseNotify Alert to close the SSL session before tearing down the TCP session with a FIN, but the kill the session straight away with a RST. Have a search on ssl-unclean-shutdown or take a look at the Apache SSL FAQ for more details. answered 20 Mar '12, 14:15  SYN-bit ♦♦ |
