Suricata

Workaround use http.header instead of http2.header cf alert http2 any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; http.header; content:"method: GET"; content:"authority: bugertor.com"; sid:4;)

Not HTTP2 specific, multi-buffer thing

Another reproducer is

alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicX"; mqtt.subscribe.topic; content:"topicY"; sid:5;)
alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicY"; sid:6;)
alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicX"; sid:7;)

on suricata-verify/tests/mqtt-sub-rules/mqtt5_sub_userpass.pcap

Philippe Antoine wrote in #note-4:

Workaround use http.header instead of http2.header cf alert http2 any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; http.header; content:"method: GET"; content:"authority: bugertor.com"; sid:4;)

Oh, that's interesting! Do you happen to know if this only works when overloading is enabled (in 6.0.x)?

Do you happen to know if this only works when overloading is enabled (in 6.0.x)?

I tested on master.
And I am not sure what you mean by overloading... What is it ?

By the way, thanks Brandon for this interesting report ;-)

Also, I would not expect http2.header; content:"method: GET"; content:"authority: bugertor.com";. to match because you want both contents in a single header (like http2.header; content:"method"; content:"GET"; does match)
But I would expect http2.header; content:"method: GET"; http2.header; content:"authority: bugertor.com"; to match and it does not...
What do you think about it as a rule writer ?
Do you understand "http header" as a single key value pair, or as all the key value pairs in a HTTP request/response ?

Philippe Antoine wrote in #note-7:

Do you happen to know if this only works when overloading is enabled (in 6.0.x)?

I tested on master.
And I am not sure what you mean by overloading... What is it ?

Enabling the http1-rules option within the http2 app layer configuration item. I stole the term from https://redmine.openinfosecfoundation.org/issues/4067

By the way, thanks Brandon for this interesting report ;-)

Also, I would not expect http2.header; content:"method: GET"; content:"authority: bugertor.com";. to match because you want both contents in a single header (like http2.header; content:"method"; content:"GET"; does match)
But I would expect http2.header; content:"method: GET"; http2.header; content:"authority: bugertor.com"; to match and it does not...
What do you think about it as a rule writer ?

I do not like it. I think this is a large difference from the behavior of http.header which "contains all of the extracted headers in a single buffer".

Do you understand "http header" as a single key value pair, or as all the key value pairs in a HTTP request/response ?

"as all the key value pairs in a HTTP request/response" only because it is this way with http.header

Very often we need the ability to write rules on the unique combination of headers and their values. The inability to combine multiple headers names and their values severally limits the rules that can be created, in this case, specific to HTTP/2, though apparently other protocols as well.

The completion of https://redmine.openinfosecfoundation.org/issues/4067 and the new default configuration in suri 7 which enables http1-rules helps a lot to workaround the current limitations of http2.header, though I see it as a problematic limitation non the less.

So, trying to sump up, there are 2 issues :
- http2.header should match http.header behavior even if I do not like this name, I can rename the current http2.header keyword to http2.single_header or such...
- multi buffer should have a mechanism to match different content on different buffer

How does that sound ?

alert http any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; http.header; content:"method: GET"; http.header; content:"authority: bugertor.com"; sid:4;). works on master-6.0.x with http1-rules

Philippe Antoine wrote in #note-9:

So, trying to sump up, there are 2 issues :
- http2.header should match http.header behavior even if I do not like this name, I can rename the current http2.header keyword to http2.single_header or such...

Ok, this seems great. I agree, I've never been a fan of the name and I've always wondered why it wasn't http.headers (plural) but I assume the answer is legacy compatibility.

- multi buffer should have a mechanism to match different content on different buffer

Sorry, I'm not sure I fully understand/follow this, can you provide more detail?

How does that sound ?

alert http any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; http.header; content:"method: GET"; http.header; content:"authority: bugertor.com"; sid:4;). works on master-6.0.x with http1-rules

Awesome, I learned something new there!

Brandon, what do you think about https://github.com/OISF/suricata/pull/8371 ?

I'll be honest, I am not familiar enough with Suri's code base (or code in general) to make any judgment about how this looks.

I have to rely on the PR/Code Review process to flush this out!

Thinking about this I agree we need a solution but also agree that the http_header / http.header keyword is poorly named. How about we do something like

http.request_header - matches each individual header (the single_header suggestion)
http.request_headers - http.header behavior limited to requests
http.request_headers.raw - http.header.raw for requests
http.response_header
http.response_headers
http.response_headers.raw

These would all apply to http1 and http2, where they can be limited to a http version through alert http1 or I suppose http.protocol; content:"HTTP/1"

But we keep old http.header for compatibility, right ?
And do we change http2.header behavior ? to match the one from http.header (while creating http.request_header to have the single header feature)

http_header and http.header need to stay as is.

Wrt http2.header, we should probably remove it. It's not part of a stable release as a non-experimental release yet, so we still have freedom there.

See https://github.com/OISF/suricata/pull/8615

Sorry, i'm a bit late getting caught up here, but regarding a solution to support buffers of individual headers, I'd rather see this feature request implemented

https://redmine.openinfosecfoundation.org/issues/5775

https://github.com/OISF/suricata/pull/9013 for adding a warning in master6