Option to make Bro willing to decode http sessions not preceded by tcp handshake?

I use Bro in the context of Security Onion, and I find that recurrently session extraction with capME
does not get the whole session, especially with tcp/80 connections that might be kept alive for several minutes while servicing multiple http requests. The extracted subset of the session packets are valid http requests and replies, but Bro does not decode them as http, only as a tcp/80 connection, if the tcp handshake packets are not at the start of the pcap.

For example, with a pcap containing just a single http request packet or a request and reply packet, this command outputs no http session data and writes no http.log file.

bro -r /example.cap /opt/bro/share/bro/sguild_bro/TCPUDPFlow.bro

but if that pcap has the 3 tcp handshake packets at the front, Bro outputs session data and an http.log file.

I assume that Bro does not consider a stream of tcp/80 packets to be valid http traffic if the tcp handshake is missing. Is there any way to ask Bro to be more forgiving about this? Perhaps a no_sweat_the_handshake option? If so, I believe it would substantially cut down on the number of capME failures experienced by Security Onion users.


That change to the http analyzer has long been needed, but we haven't had the available time to implement it yet because we would need to implement a stream resynchronization mechanism for the HTTP analyzer and it's not trivial with the current analyzer.


Thanks, Seth. I appreciate the update on the issue. For now I can substantially mitigate this problem by increasing the pcap file rollover size so that more often the entire stream to be extracted is in a single pcap file to begin with. All the same, it will be great when you all find the time to implement stream resynchronization in the HTTP analyzer.

I have really grown to appreciate and lean on Bro more over the last few years. When I got started with Security Onion I saw Bro as an interesting add-on alongside Snort/Suricata but now it’s like a major part of the engine of the whole NSM solution. Thanks for all your great work on this!