Suricata

This has been observed with suricata 2.0, specifically with HTTP transactions, although I wonder if the issue is more general than that.

When suricata sees a FIN from the server to the client, StreamTcpHandleFin is called, which sets STREAMTCP_STREAM_FLAG_CLOSE_INITIATED in the stream flags. When the reassembly layer next processes any packet in the client direction for the stream, STREAM_EOF is set, which then results in APP_LAYER_PARSER_EOF being set. Once APP_LAYER_PARSER_EOF is set, the transaction logging code considers it safe to log the transaction. However, there is no guarantee at that point that all the ACKs in the opposite (client to server) direction have been seen and processed and that the reassembly layer has passed all the data in the response to the app parser. As a result, I've observed response data being parsed by libhtp after the transaction has already been logged. This behaviour can result in, e.g., incorrect response length values being output to the log and potentially missing header values. I'm not sure if there are more far reaching implications.