Question: Suricata and sslproxy

[primmus]

Hello, is it possible to make suricata-ids read the sslproxy header, to identify the source and destination correctly?

Best regards;
Primmus

[sonertari]

You are asking the same question as in here and here. I had seen those requests before, but I am not familiar with the source code of Suricata (I have used it, but never needed to look into its source code, and can't remember much). I don't even know/remember if it has preprocessors as with Snort. But even if it doesn't have preprocessors, it must be still possible as I did with other UTM software on UTMFW. I can try to look into it in the future, but I cannot promise anything.

[victorjulien]

Hi, I'm looking at this. Will be sharing a PoC as a PR to the Suricata repository soon.

[sonertari]

Hi Victor, that's great. When you push your PR, please inform us (this issue) too. I will try to test it. Thanks.

[Raifeg]

@victorjulien Hi, any news on this?

[tugtugtug]

Hi @victorjulien, thanks for creating https://redmine.openinfosecfoundation.org/issues/4122 to track the effort. We were hoping to see some changes in suricata 7.0, but it looks like this is pushed out to 8 again.

Any thought has put into the change where you would detect and remove the inserted header? We don't really require the detection to operate on the original src/dst tuples, but would like to have the detection still operate on the content, i.e. without removing the header, the protocol detection will unlikely find the correct protocol.
We are looking at an intermediate solution before 8.0 release(even with some changes to suricata). There is the replace action with the content filter, would that be useful if modified to remove the header? One restriction we found for the replace action was that the length of the replacement has to match. Is there any way to workaround that? Or is it best to alter the packet at even an earlier stage? and recalculate the checksum?

[victorjulien]

@sonertari your webinar was the trigger for me to finally revisit this.

I've implemented support for the normal ssl/autossl modes in OISF/suricata#13960. It's still a draft, it will likely need more work before we'll merge it. Question: from the Suricata perspective it would be easier if the http mode also prepends the SSLproxy header, so before the HTTP request line, is this possible as a config option?

[sonertari]

@victorjulien that's fantastic news! Thank you very much for taking the initiative to revisit this and for working on the initial support in OISF/suricata#13960.

Regarding your question about the HTTP mode header placement:

I fully agree that the HTTP standards expect the Request-Line to be at the absolute top. However, since the custom SSLproxy header is an internal modification that is always stripped before traffic leaves the proxy, inserting it as the first line is indeed technically safe for the external network.

So, yes, I can implement this as a configurable option to allow for better integration with Suricata's parsing logic.

I am planning to introduce a global (or potentially proxyspec-specific) boolean option, perhaps named SSLproxyHeaderAtTop, which controls whether the header is inserted as the very first line of the request stream (true) or immediately after the Request-Line (false, the standard HTTP position).

For the standalone SSLproxy tool, I will set the default to the standard-compliant position (false). However, for my UTMFW project—where Suricata will be the primary consumer—I will default this option to true once your work is merged.

I appreciate you raising this; it will ensure we achieve the best possible performance for the Suricata integration!