Update on ICAP integration proposal: Working implementation of SSLproxy (icap branch) & icapsuricata (`libsuricata` service)

Developers
1

Hi All,

Following up on my ICAP integration proposal from earlier this year—specifically the architectural shift discussed in this topic on the Suricata forum—I wanted to share a major update regarding working software implementations for both components.

Over the last few months, I have moved this from a theoretical proposal to working prototypes proving the validity of the ICAP model for inline decryption and deep inspection.

Here is the current status:

  1. SSLproxy (icap branch): The icap branch of SSLproxy now features a full, functional ICAP client implementation. It has been validated against standard ecosystem services including c-icap (echo/ex206), squidclamav, E2Guardian, and my newly developed custom Suricata service plugin.
  2. icapsuricata (c-icap service module): To bridge the gap between the proxy layer and the engine, I have launched icapsuricata. This is a custom c-icap service module running Suricata in library mode (libsuricata). Rather than passive interface capture, it interacts inline directly with the proxy stream. The module processes c-icap data blocks, dynamically constructs sequentially aligned, in-memory TCP/IP packet streams, and injects them straight into libsuricata for real-time app-layer tracking and signature detection. To ensure high performance and zero heap memory fragmentation, it utilizes a custom single-writer, dual-reader circular ring buffer.

Please note that both codebases are actively in a Work-In-Progress (WIP) phase and are intended as architectural proofs-of-concept rather than production-ready artifacts. However, they serve as a concrete, working implementation of the proposed ICAP paradigm.

I would highly value your technical feedback, comments, or suggestions on this approach.

Best,
Soner