ssl proxy and decrypted forwarding

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ssl proxy and decrypted forwarding

Sam Castellano
Good morning,
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.  

Best regards


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ssl proxy and decrypted forwarding

Alex Rousskov
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
traffic.


HTH,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: ssl proxy and decrypted forwarding

Sam Castellano
Thank you for the swift response Alex, my main goal is to be able to use suricata or snort to analyze the decrypted https traffic/payload. Suricata/Snort is looking at the interface and naturally will only see the https messages encrypted as the squid server receives the messages encrypted and sends them out encrypted. So I am actually trying to send the proxied https messages decrypted. I hope that makes sense.... Sorry if I misunderstood your explanation and all the help is greatly appreciated so thank you !

Best regards-

Sam Castellano


----- Original Message -----
From: "Alex Rousskov" <[hidden email]>
To: "Sam Castellano" <[hidden email]>, "squid-users" <[hidden email]>
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
traffic.


HTH,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ssl proxy and decrypted forwarding

Alex Rousskov
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:

http://lists.squid-cache.org/pipermail/squid-users/2016-September/012689.html


HTH,

Alex.

> ----- Original Message -----
> From: "Alex Rousskov" <[hidden email]>
> To: "Sam Castellano" <[hidden email]>, "squid-users" <[hidden email]>
> 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
> traffic.
>
>
> HTH,
>
> Alex.
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users