Hi All,
I’ve just published a new piece that I think is relevant to the current work on the SSLproxy support PR (#13960): I Tried to Add HTTP/2 to SSLproxy. Here is Why I Stopped. (We Need ICAP.).
To be blunt: The current Divert Mode implementation in SSLproxy is a dead end for H2 and H3. While it works for H1, it will never enable Suricata to inspect H2/H3 traffic from SSLproxy without a massive, fragile protocol-translation layer that doesn’t scale.
If you think Divert mode was a mistake, think again—even Blue Coat (ProxySG) uses a similar architecture. But they hit the same wall with H2/H3, which is exactly why their ecosystem eventually offloaded the ‘heavy lifting’ to ICAP-based Content Analysis engines.
I’m elevating the urgency of my ICAP proposal from the PreSuriCon webinar. And I suggest another solution to pass decrypted packets to Suricata, instead of my previous suggestion (a new DAQ module with ICAP server support + packet emulation), which had an unnecessary emulation overhead just to satisfy Suricata’s reassembly needs, as I hinted at the webinar.
The new proposal: Once I implement ICAP client support in SSLproxy, we should develop a standalone ICAP server that integrates Suricata as a library.
This avoids the “packet emulation” mess entirely. Instead of pretending to be a network interface to feed Suricata, we use Suricata’s inspection power directly on the stream buffers provided by the ICAP lifecycle.
I realize that Library Mode isn’t fully mature yet (per recent forum discussions like this), but I believe it is the best path forward if we want to support H2/H3 and finally unblock UDP 443.
In summary, I think ICAP and Library Mode seem to be the missing links for modern protocol inspection. What do you think?
Best,
Soner