Feature #5973


warn when HTTP rules will only work for a specific version of HTTP

Added by Brandon Murphy 11 months ago. Updated 4 months ago.

Target version:


As a rule writer, I'd like to be warned should if a rule only supports certain versions of HTTP due to use of keywords which only support certain HTTP versions.

This feature was mentioned within

Should we warn on a rule alert http that is only for HTTP1 or HTTP2 based on its keywords ?

I see no reason to not warn on this condition and as such am formally requesting it.

Side Note:
I could see some other use cases such as warning when nocase isn't applied to http.header_names, http.header, etc. Though perhaps those use cases are not good fits for the engine to identify.

Actions #1

Updated by Victor Julien 9 months ago

  • Target version changed from TBD to 8.0.0-beta1

The warning should make sure not to ever warn on legacy keywords if HTTP/2 doesn't support them.

Also not sure if a warning is the proper way, as as a valid rule shouldn't really warn ideally. Wonder if it is more something for engine analysis.

Actions #2

Updated by Philippe Antoine 4 months ago

Would you have an example rule where you would want such a warning ?

Actions #3

Updated by Brandon Murphy 4 months ago

Victor Julien wrote in #note-1:
Wonder if it is more something for engine analysis.

I think that's a great idea.

Philippe Antoine wrote in #note-2:
Would you have an example rule where you would want such a warning ?

sure! these two come to mind quickly.

alert http any any -> any any (msg:"http.start only supports HTTP/1"; flow:established,to_server; http.start; content:"GET /foo"; startswith; content:"|0d 0a|Host|3a 20|"; within:15; sid:1;)
alert http any any -> any any (msg:"http.msg only populated with content on HTTP/1"; flow:established,to_server; http.msg; content:"Found"; sid:2;)

There might be others, but i'm not 100% sure they'd be good for the engine. I suppose as engine-analysis they would be ok.

Things like the use of pseudo headers on contents, which would indicate the rule would only work with HTTP/2. In that example, the RFC's defined list of :pseudo headers ( would be used to identify the usage.

capital letters in contents when to_lowercase transformation is applied to a buffer
capital letters in contents of http.header_names (would indicate it might be HTTP/1 only)

when header_lowercase is applied to a buffer, and content matches contain something that matches the same logic as header_lowercase [^\x3a]+\x3a[^\r\n]+[\r\n]+ bring that content to the rule writers attention.

Idk, I'm just brainstorming here, some if these we can probably do within ET's own rule analysis.


Also available in: Atom PDF