search

sonertari / SSLproxy

Transparent SSL/TLS proxy for decrypting and diverting network traffic to other programs, such as UTM services, for deep SSL inspection
BSD 2-Clause "Simplified" License
388 stars 101 forks source link

Question: Suricata and sslproxy #8

Open primmus opened 6 years ago

primmus commented 6 years ago

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

Best regards; Primmus

sonertari commented 6 years ago

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 commented 3 years ago

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

sonertari commented 3 years ago

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

Raifeg commented 2 years ago

@victorjulien Hi, any news on this?

tugtugtug commented 1 year ago

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?