Re: [squid-users] Confirmation page not working

[TarotApprentice]

Thanks. The page wasn’t loading at all. It does now.

> On 18 Apr 2020, at 2:36 am, Francesco Chemolli  wrote:
> 
> 
> Hi,
>   there was a problem on the server, now fixed.
> Apologies
> 
>> On Fri, Apr 17, 2020 at 4:08 PM Antony Stone 
>>  wrote:
>> On Friday 17 April 2020 at 15:32:38, TarotApprentice wrote:
>> 
>> > Trying to visit the confirmation page at
>> > http://lists.squid-cache.org/confirm/squid-users/ but it doesn’t seem to
>> > be responding. I’ve tried over a couple of days.
>> 
>> When you say "not responding", do you mean you get no page content shown in 
>> your browser, or do you mean that you fill in the confirmation string and 
>> click 
>> on 'submit' but it then doesn't accept your confirmation?
>> 
>> The page itself loads fine for me here, and I've only ever confirmed mailman 
>> subscriptions by email - just reply to the email you got asking you to visit 
>> the confirmation page, making sure you reply from the address you asked to 
>> subscribe to the list.
>> 
>> No need to change anything about the email you get, just do a "reply" and 
>> "send" exactly as it is.
>> 
>> 
>> Antony.
>> 
>> -- 
>> Success is a lousy teacher.  It seduces smart people into thinking they 
>> can't 
>> lose.
>> 
>>  - William H Gates III
>> 
>>Please reply to the list;
>>  please *don't* CC 
>> me.
>> ___
>> squid-users mailing list
>> squid-users@lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
> 
> 
> -- 
> Francesco
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] 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" 
> To: "Sam Castellano" , "squid-users" 
> 
> 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
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Confirmation page not working

[Francesco Chemolli]

Hi,
  there was a problem on the server, now fixed.
Apologies

On Fri, Apr 17, 2020 at 4:08 PM Antony Stone <
antony.st...@squid.open.source.it> wrote:

> On Friday 17 April 2020 at 15:32:38, TarotApprentice wrote:
>
> > Trying to visit the confirmation page at
> > http://lists.squid-cache.org/confirm/squid-users/ but it doesn’t seem to
> > be responding. I’ve tried over a couple of days.
>
> When you say "not responding", do you mean you get no page content shown
> in
> your browser, or do you mean that you fill in the confirmation string and
> click
> on 'submit' but it then doesn't accept your confirmation?
>
> The page itself loads fine for me here, and I've only ever confirmed
> mailman
> subscriptions by email - just reply to the email you got asking you to
> visit
> the confirmation page, making sure you reply from the address you asked to
> subscribe to the list.
>
> No need to change anything about the email you get, just do a "reply" and
> "send" exactly as it is.
>
>
> Antony.
>
> --
> Success is a lousy teacher.  It seduces smart people into thinking they
> can't
> lose.
>
>  - William H Gates III
>
>Please reply to the
> list;
>  please *don't* CC
> me.
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>


-- 
Francesco
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] 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" 
To: "Sam Castellano" , "squid-users" 

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.

smime.p7s
Description: S/MIME Cryptographic Signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] 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
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] 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 



smime.p7s
Description: S/MIME Cryptographic Signature
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Confirmation page not working

[Antony Stone]

On Friday 17 April 2020 at 15:32:38, TarotApprentice wrote:

> Trying to visit the confirmation page at
> http://lists.squid-cache.org/confirm/squid-users/ but it doesn’t seem to
> be responding. I’ve tried over a couple of days.

When you say "not responding", do you mean you get no page content shown in 
your browser, or do you mean that you fill in the confirmation string and click 
on 'submit' but it then doesn't accept your confirmation?

The page itself loads fine for me here, and I've only ever confirmed mailman 
subscriptions by email - just reply to the email you got asking you to visit 
the confirmation page, making sure you reply from the address you asked to 
subscribe to the list.

No need to change anything about the email you get, just do a "reply" and 
"send" exactly as it is.


Antony.

-- 
Success is a lousy teacher.  It seduces smart people into thinking they can't 
lose.

 - William H Gates III

   Please reply to the list;
 please *don't* CC me.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] dynamic ACLs

[Amos Jeffries]

On 16/04/20 9:09 pm, Vieri wrote:
> Hi,
> 
> In sslbump tproxy "mode" one cannot authenticate user to limit/allow their 
> access to web content.
> 
> I was thinking however of making a web form with auth within a custom Squid 
> error page. This way a user would "automatically" whitelist a web site and 
> have access to it while the IT dep. would know which user accessed where 
> despite the site being blacklisted.
> 
> From the error page I can tell which ACL is blocking that site so I could 
> create an "exception" ACL for that ACL.
> My question is: can this whitelist or graylist ACL be dynamic without needing 
> to reload Squid, a bit like ipsets with iptables/nftables without the need to 
> reload rules?
> 


Squid comes with an external ACL helper that authorizes access based on
DB entries. You can use any system you like to manage the DB entries.
 see



Amos
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] dynamic ACLs

[Alex Rousskov]

On 4/16/20 5:09 AM, Vieri wrote:
> In sslbump tproxy "mode" one cannot authenticate user to limit/allow their 
> access to web content.
> 
> I was thinking however of making a web form with auth within a custom Squid 
> error page. This way a user would "automatically" whitelist a web site and 
> have access to it while the IT dep. would know which user accessed where 
> despite the site being blacklisted.
> 
> From the error page I can tell which ACL is blocking that site so I could 
> create an "exception" ACL for that ACL.
> My question is: can this whitelist or graylist ACL be dynamic without needing 
> to reload Squid, a bit like ipsets with iptables/nftables without the need to 
> reload rules?

Yes, there are several ways to change Squid decisions without
reconfiguring Squid. The simplest one is the "external acl" mechanism:
http://www.squid-cache.org/Doc/config/external_acl_type/
 Alex.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Confirmation page not working

[TarotApprentice]

Trying to visit the confirmation page at 
http://lists.squid-cache.org/confirm/squid-users/ but it doesn’t seem to be 
responding. I’ve tried over a couple of days.

MarkJ ___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users