[squid-users] ssl proxy and decrypted forwarding
rousskov at measurement-factory.com
Fri Apr 17 18:20:38 UTC 2020
On 4/17/20 12:00 PM, Sam Castellano wrote:
> Suricata/Snort is looking at the interface
If listening on a network interface is all these tools can do, and you
do not want to modify Squid, then you can [pay somebody to] write an
eCAP adapter (or an ICAP service) that will send decrypted messages to
that network interface as if it were plain HTTP/TCP/IP/Ethernet traffic.
It is not easy to do, and there are dangers related to (and limitations
of) this approach, but I know it is possible because we have
successfully done that for a customer a few years ago.
For a bit more info, follow a similar old squid-users thread:
> ----- Original Message -----
> From: "Alex Rousskov" <rousskov at measurement-factory.com>
> To: "Sam Castellano" <scastellano at quadrantsec.com>, "squid-users" <squid-users at lists.squid-cache.org>
> Sent: Friday, April 17, 2020 11:49:13 AM
> Subject: Re: [squid-users] ssl proxy and decrypted forwarding
> On 4/17/20 11:22 AM, Sam Castellano wrote:
>> My question relates to ssl bumping and potentially Icap/Ecap
>> functionality. I currently have ssl bump/ interception working and
>> communicating with a local ICAP server. Im trying to understand the
>> process of how the decrypted data gets sent to the ICAP server for
>> analysis in things such as clamav etc. My goal is to have the decrypted
>> traffic analyzed by Suricata preferably on a separate box if possible.
> I do not know what particular information you are looking for, but ICAP
> mechanics are documented in RFC 3507 while eCAP mechanics are documented
> at www.e-cap.org.
> If you are worried about exposing proxied HTTP[S] messages in transit to
> your ICAP service, then consider using a "Secure ICAP" service (for a
> starting point, look for those two words in squid.conf.documented).
> N.B. Neither ICAP nor eCAP know about SslBump. In an SslBump context,
> they just get CONNECT requests and the HTTP messages decrypted by Squid.
> The same is true for the majority of Squid features -- while inside
> Squid, decrypted HTTP traffic is usually handled similar to plain HTTP
More information about the squid-users