Websockets 2695 v8

[catenacyber]

Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/2695
https://redmine.openinfosecfoundation.org/issues/6647

Describe changes:

• app-layer: websockets protocol support
• rust : derive for protocol enumerations strings
• enip: register on default port 44818 also for TCP (as is done on UDP)
• http2: add newer settings, including the one for websocket over HTTP/2 cf https://www.rfc-editor.org/rfc/rfc8441#section-3

SV_BRANCH=pr/1550

OISF/suricata-verify#1550 justrebased and force-pushed

#10091 with

• trait for derive and hopefully fixed compilation with older rust

I think this is good enough for a first version even if there may be improvements (that can happen in later tickets) :

• payload logging : waiting for feedback wether this is only for alerts, or also for websocket event
• using latest HTTP/1 transaction in a single rule, instead of splitting rule and using flowbits
• support websockets over HTTP/2 : need pcap
  This is a big one as websockets over HTTP/2 only use a single HTTP/2 stream and not the whole TCP connection which keeps having newer regular HTTP/2 streams

[catenacyber]

Maybe I should change the fin keyword to be the complete first byte, and implement https://redmine.openinfosecfoundation.org/issues/6648 to march on the reserved bits (like the one that got used for compression) (can still be matched now with frames and byte_extract I guess)

[suricata-qa]

ERROR:

ERROR: QA failed on SURI_TLPW1_files_sha256.

Pipeline 17183

[jasonish]

So you should now be able to do something like:

impl<T> TryFrom<&dyn Enum<T>> for DetectUintData<T> {
    type Error = ();

    fn try_from(value: &dyn Enum<T>) -> Result<Self, Self::Error> {
        todo!()
    }
}

instead of having this method as part of the trait.

[jasonish]

Alternatively naming.. This is an enum specifically for use in detection with a direct mapping from a name to an integer value?

[catenacyber]

So you should now be able to do something like:

impl<T> TryFrom<&dyn Enum<T>> for DetectUintData<T> {
    type Error = ();

    fn try_from(value: &dyn Enum<T>) -> Result<Self, Self::Error> {
        todo!()
    }
}

instead of having this method as part of the trait.

So I think the prototype fn to_detect_ctx(s: &str) -> Option<DetectUintData<T>> is right as it takes a string as input, and resorts to generic integer parsing if this is not an enum string

This is an enum specifically for use in detection with a direct mapping from a name to an integer value?

The enum is also used in logging (not only for alerts). Was it your question ?

[jasonish]

It just seems out of place, with respect to naming. We have a rather generic trait named Enum, but then we have this method to_detect_ctx that doesn't even take &self.

Some more comments in next PR.

[catenacyber]

Maybe the trait can be better named indeed.

method to_detect_ctx that doesn't even take &self.

But I do not want to use the enumeration : I just want a unique association between integers and strings that goes both ways, and some helper functions around that.
Is derive+trait+enum the best way to do so ? Or do you see another way ?

[jasonish]

In the gist I posted that has the from traits, maybe a generic helper function?

[catenacyber]

Thans Jason, tried in d5f1bf2

[catenacyber]

Replaced by #10104