Suricata

Also we have currently inserted BUG_ON() inside our http parser that would be hit, if we end up seeing a response first. Currently this serves more as a debug to pick up any bugs in suricata's updated protocol detection.

Once the libhtp update comes in, this should go.

Whats the purpose of the BUG_ON? Sounds like this is a trivial DOS to everyone running this code?

We should never go through this code sequence in the first place, i.e.
response gets sent first in case of http. If we do there's a very good
chance that we would segv in detection.

The main reason why I have it in dev branch is to catch any bugs or for
missed corner cases in the new protocol detection code. Makes it easier
to debug than catch a segv later in detection, as confirmed by the bug
reports form bug_989.

Can you add a link to the upstream libhtp ticket?

I don't see a ticket for this in -

https://github.com/ironbee/libhtp/issues

Any idea if I should create a new ticket for this in libhtp issues?

Anoop Saldanha wrote:

I don't see a ticket for this in -

https://github.com/ironbee/libhtp/issues

Any idea if I should create a new ticket for this in libhtp issues?

Might be good to discuss with Ivan.

Suricata support in https://github.com/OISF/suricata/pull/3202