Bug #9276
openSuricata: HTTP header normalization changes rule-matching representation (SID 36791; behavior question)
Description
Hello Suricata maintainers,
I am reporting a repeatable detection-behavior difference from a local offline NIDS study and asking whether this is expected. This is not an assertion of a vulnerability or production impact.
Case / rule: Suricata lane, SID 36791. The frozen synthetic HTTP input combines an unusual colon/space arrangement, CRLFs, and a trailing empty-line pattern in a header. The local normalization/reserialization marker recorded a representation change from 63 bytes to 58 bytes, after which the target layout was no longer present for the rule. A controlled comparison changed only the normalized layout representation while preserving field semantics and detection conditions; Suricata changed from no alert to alert. The original 58-byte representation did not produce the alert.
Could you confirm whether this normalization and resulting rule-visible representation are expected for this input and configuration, and whether a Suricata-Verify regression test would be appropriate? This is distinct from charset guessing and from HTTP section truncation; it is limited to this synthetic case and is not a general parser or security-vulnerability claim.
Reproduction environment: local offline synthetic NIDS testing only; no live network, production deployment, or third-party target. The attached ZIP includes the PCAP, case/rule definition, replay specification, and recorded environment identity. The source experiment is from a prior recorded run; the assembled package has not been independently replayed since staging.
Thank you.
Files
No data to display