Suricata

This was found during investigation of #4858

From talk with Victor, this is a known limitation, where the chunk size is supposed to be a bit random to protect against evasion attempts.

The solution may be to use hyperscan as a streaming engine (instead of running it on different chunks/blocks)

I think this one can be postponed after 8

The solution may be to use hyperscan as a streaming engine (instead of running it on different chunks/blocks)

nice!

I was recently studying this part and realized that just keeping the match window flexible while giving it to prefilter may also work.
e.g.
content to be matched: "SURICATA"
current inspection window "AAAAAAAAAAAAAAAAABATATASURI" -> MPM will find no possible matches against the pattern for the given rule(s)
next inspection window: "CATAMMMMMMMM"

result: no match

However, if we calculated the length of the biggest pattern (usually already tracked and auto used as fast pattern), we could ask MPM to go backwards/forwards by that length in the window.
So, instead of discarding the current inspection window when no matches were found,
we keep 8 bytes from the end, when the next inspection window comes, we send "TATASURICATAMMMMMMMM" to the MPM and voila! there's a possible match!

There are some things around this that'll have to be thought through though.

Lmk wdyt?

Just to bring some precisions : there is indeed a link to #7743 but this ticket is not specially about HTTP, just TCP (with an unknown protocol for instance) see #1598