[squid-users] Squid doesn't call helper

[Kornexl, Anton]

Squid 4.10 on Ubuntu 20.04

The configured program is started but not called (or the result not used)
The authentication window does not show up in the browser
All request are denied because acl proxyuser doesn't match
The same config runs on squid 3.5.27 on Ubuntu 18.04 and squid 4.13 on opensuse 
4.13

How can i debug this problem
Other helpers are also not called/used

The squid user can execute the configured program
/usr/local/bin/mysql_auth and returns an OK

sudo -u squid /usr/local/bin/mysql_auth
test testing
OK

---
auth_param basic program /usr/local/bin/mysql_auth
auth_param basic children 10 startup=5 idle=1
auth_param basic utf8 on
auth_param basic realm "Squid proxy-caching web server"
auth_param basic credentialsttl 2 hours

acl jufi1 src 1.2.3.4/32
acl jufi1-6 src  2a01:.::2
acl jufi2 src 1.2.3.5/32
acl jufi2-6 src 2a01:.::2

acl proxyusers proxy_auth REQUIRED

http_access allow jufi1
http_access allow jufi1-6
http_access allow jufi2
http_access allow jufi2-6

http_access allow proxyusers

---

Yours
Anton Kornexl
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] sslbump https intercepted or tproxy

[Vieri]

Hi,

It's unclear to me if I can use TPROXY for HTTPS traffic.

If I divert traffic and use tproxy in the Linux kernel and then set this in 
squid:

https_port 3130 tproxy ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=16MB cert=/etc/ssl/squid/proxyserver.pem

it seems to be working fine, just as if I were to REDIRECT https traffic and 
then use this in Squid:

https_port 3130 intercept ssl-bump generate-host-certificates=on 
dynamic_cert_mem_cache_size=16MB cert=/etc/ssl/squid/proxyserver.pem

So, does anyone know if it's not recommended / not supported to use tproxy with 
https traffic?
I'm asking because I don't see any issues with tproxy, with the added advantage 
of being able to route on the gateway per source IP addr. (in intercepted mode, 
the source is always Squid).

Are there any reasons for which one would not use TPROXY with HTTPS?

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

Re: [squid-users] SSL issue on Squid version 4 after blacklisting

[Alex Rousskov]

On 10/19/20 1:16 PM, Eliezer Croitor wrote:

> To get a response you would need to respond in the Bugzilla.
> Maybe Alex might be able to answer some of your questions about the subject.

FWIW, the October 19 email from Ankit Dixit (quoted below) did not reach
me. It probably did not reach others on squid-users either because the
mailing list archive does not show it.

The short answer to that "what needs to be done" question is "serious
development". It is not a simple change, but we are making progress with it.

Alex.

  

> *From:* DIXIT Ankit 
> *Sent:* Monday, October 19, 2020 3:11 PM
> *To:* Eliezer Croitor 
> *Cc:* 'Squid Users' 
> *Subject:* RE: SSL issue on Squid version 4 after blacklisting
> 
>  
> 
> Elizer,
> 
>  
> 
>  1. I am not able to identify from below like what exactly needs to be
> done and in which file?
> 
>  
> 
> * Short-term: Essentially disable OpenSSL built-in certificate
> validation (for certificates with missing intermediate CAs) and perform
> that validation from Squid, using X509_verify_cert(), after
> SSL_connect() returns control to Squid and Squid fetches the missing
> CAs. This approach still requires some non-trivial Squid development and
> keeping an eye on OpenSSL built-in validation logic, but it can be
> completed without OpenSSL modifications and, IMHO, without replicating a
> lot of OpenSSL internal validation logic.
> 
>  
> 
> * Long-term: We need a new OpenSSL callback for pausing OpenSSL
> processing after TLS v1.3 server handshake is decrypted and before
> certificate validation starts.
> 
>  
> 
>  2. Apart from above, I want to also understand if we have below
> configuration in Squid version 3.5 in squid.conf then how would I
> replace and to what ,if we move to Squid version 4.12
> 
>  
> 
> sslproxy_cipher
> HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS
> 
> sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_ECDH_USE
> 
>  
> 
> *Regards,*
> 
> *Ankit Dixit|IS Cloud Team*
> 
> *Eurostar International Ltd*
> 
> *Times House | Bravingtons Walk | London N1 9AW*
> 
> *Office: +44 (0)207 84 35550 (Extension– 35530)*
> 
>  
> 
> *From:* Eliezer Croitor  >
> *Sent:* Monday, October 12, 2020 12:38 PM
> *To:* DIXIT Ankit  >
> *Cc:* 'Squid Users'  >
> *Subject:* RE: SSL issue on Squid version 4 after blacklisting
> 
>  
> 
>  
> 
> Hey Dixit,
> 
>  
> 
> Have you seen the next bug report:
> 
> https://bugs.squid-cache.org/show_bug.cgi?id=5067#c4
> 
>  
> 
> Alex/Amos: I assume that this specific issue deserve a DEBUG which will
> describe and relate to this BUG:5067 report.
> 
>  
> 
> Eliezer
> 
>  
> 
> 
> 
> Eliezer Croitoru
> 
> Tech Support
> 
> Mobile: +972-5-28704261
> 
> Email: ngtech1...@gmail.com 
> 
>  
> 
> *From:* DIXIT Ankit  >
> *Sent:* Friday, September 25, 2020 4:22 PM
> *To:* Eliezer Croitor  >; 'Squid Users'
>  >
> *Subject:* RE: SSL issue on Squid version 4 after blacklisting
> 
>  
> 
> Elizer/Team,
> 
>  
> 
> Any help would be appreciated.
> 
>  
> 
> *Regards,*
> 
> *Ankit Dixit|IS Cloud Team*
> 
> *Eurostar International Ltd*
> 
> *Times House | Bravingtons Walk | London N1 9AW*
> 
> *Office: +44 (0)207 84 35550 (Extension– 35530)*
> 
>  
> 
> *From:* DIXIT Ankit
> *Sent:* Tuesday, September 15, 2020 1:24 PM
> *To:* Eliezer Croitor  >; 'Squid Users'
>  >
> *Subject:* SSL issue on Squid version 4 after blacklisting
> 
>  
> 
> *_Subject changed_*
> 
> * *
> 
> Elizer/Team,
> 
>  
> 
> Connecting with you again after we upgraded to Squid version 4.
> 
>  
> 
> We have blacklisted the domain categories  on Squid Proxy, but we are
> getting below exception in cache.log and due to this internet is not
> flowing from client servers via squid.
> 
> This blacklist category is having thousands of blacklisted domains.
> 
>  
> 
> kid1| Error negotiating SSL on FD 33: error:14090086:SSL
> routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)
> 
> kid1| Error negotiating SSL connection on FD 26: (104) Connection reset
> by peer
> 
>  
> 
> Is there any specific ssl certificate, we need to configure? Or any
> other issue, you see here?
> 
>  
> 
>  
> 
> *Regards,*
> 
> *Ankit Dixit|IS Cloud Team*
> 
> *Eurostar International Ltd*
> 
> *Times House | Bravingtons Walk | London N1 9AW*
> 
> *Office: +44 (0)207 84 35550 (Extension– 35530)*
> 
>  
> 
> *From:* DIXIT Ankit
> *Sent:* Monday, July 6, 2020 8:50 AM
> *To:* Eliezer Croitor  >; 'Squid Users'
>  >
> *Subject:* RE: [squid-users] Squid memory consumption problem
> 
>  
> 
> Elizer,
> 
>  
> 
> SSL was failing for few applications but was working fine for other
> applications. So 

Re: [squid-users] SSL issue on Squid version 4 after blacklisting

[Eliezer Croitor]

Hey Dixit,

 

To get a response you would need to respond in the Bugzilla.

Maybe Alex might be able to answer some of your questions about the subject.

 

All The Bests,

Eliezer

 



Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: ngtech1...@gmail.com  

 

From: DIXIT Ankit  
Sent: Monday, October 19, 2020 3:11 PM
To: Eliezer Croitor 
Cc: 'Squid Users' 
Subject: RE: SSL issue on Squid version 4 after blacklisting

 

Elizer,

 

1.  I am not able to identify from below like what exactly needs to be done 
and in which file?

 

* Short-term: Essentially disable OpenSSL built-in certificate validation (for 
certificates with missing intermediate CAs) and perform that validation from 
Squid, using X509_verify_cert(), after SSL_connect() returns control to Squid 
and Squid fetches the missing CAs. This approach still requires some 
non-trivial Squid development and keeping an eye on OpenSSL built-in validation 
logic, but it can be completed without OpenSSL modifications and, IMHO, without 
replicating a lot of OpenSSL internal validation logic.

 

* Long-term: We need a new OpenSSL callback for pausing OpenSSL processing 
after TLS v1.3 server handshake is decrypted and before certificate validation 
starts.

 

2.  Apart from above, I want to also understand if we have below 
configuration in Squid version 3.5 in squid.conf then how would I replace and 
to what ,if we move to Squid version 4.12

 

sslproxy_cipher 
HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

sslproxy_options NO_SSLv2,NO_SSLv3,SINGLE_ECDH_USE 

 

Regards,

Ankit Dixit|IS Cloud Team

Eurostar International Ltd

Times House | Bravingtons Walk | London N1 9AW

Office: +44 (0)207 84 35550 (Extension– 35530)

 

From: Eliezer Croitor mailto:ngtech1...@gmail.com> > 
Sent: Monday, October 12, 2020 12:38 PM
To: DIXIT Ankit mailto:ankit.di...@eurostar.com> >
Cc: 'Squid Users' mailto:squid-users@lists.squid-cache.org> >
Subject: RE: SSL issue on Squid version 4 after blacklisting

 




 

Hey Dixit,

 

Have you seen the next bug report:

https://bugs.squid-cache.org/show_bug.cgi?id=5067#c4

 

Alex/Amos: I assume that this specific issue deserve a DEBUG which will 
describe and relate to this BUG:5067 report.

 

Eliezer

 



Eliezer Croitoru

Tech Support

Mobile: +972-5-28704261

Email: ngtech1...@gmail.com  

 

From: DIXIT Ankit mailto:ankit.di...@eurostar.com> > 
Sent: Friday, September 25, 2020 4:22 PM
To: Eliezer Croitor mailto:ngtech1...@gmail.com> >; 
'Squid Users' mailto:squid-users@lists.squid-cache.org> >
Subject: RE: SSL issue on Squid version 4 after blacklisting

 

Elizer/Team,

 

Any help would be appreciated.

 

Regards,

Ankit Dixit|IS Cloud Team

Eurostar International Ltd

Times House | Bravingtons Walk | London N1 9AW

Office: +44 (0)207 84 35550 (Extension– 35530)

 

From: DIXIT Ankit 
Sent: Tuesday, September 15, 2020 1:24 PM
To: Eliezer Croitor mailto:ngtech1...@gmail.com> >; 
'Squid Users' mailto:squid-users@lists.squid-cache.org> >
Subject: SSL issue on Squid version 4 after blacklisting

 

Subject changed

 

Elizer/Team,

 

Connecting with you again after we upgraded to Squid version 4.

 

We have blacklisted the domain categories  on Squid Proxy, but we are getting 
below exception in cache.log and due to this internet is not flowing from 
client servers via squid. 

This blacklist category is having thousands of blacklisted domains.

 

kid1| Error negotiating SSL on FD 33: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0)

kid1| Error negotiating SSL connection on FD 26: (104) Connection reset by peer

 

Is there any specific ssl certificate, we need to configure? Or any other 
issue, you see here?

 

 

Regards,

Ankit Dixit|IS Cloud Team

Eurostar International Ltd

Times House | Bravingtons Walk | London N1 9AW

Office: +44 (0)207 84 35550 (Extension– 35530)

 

From: DIXIT Ankit 
Sent: Monday, July 6, 2020 8:50 AM
To: Eliezer Croitor mailto:ngtech1...@gmail.com> >; 
'Squid Users' mailto:squid-users@lists.squid-cache.org> >
Subject: RE: [squid-users] Squid memory consumption problem

 

Elizer,

 

SSL was failing for few applications but was working fine for other 
applications. So we reverted back to old version.

I am not sure what ssl certificate dependency was there. 

 

Would be great, if you can suggest memory leak solutions in 3.12 version.

 

Regards,

Ankit Dixit|IS Cloud Team

Eurostar International Ltd

Times House | Bravingtons Walk | London N1 9AW

Office: +44 (0)207 84 35550 (Extension– 35530)

 

From: Eliezer Croitor mailto:ngtech1...@gmail.com> > 
Sent: Sunday, July 5, 2020 5:58 PM
To: DIXIT Ankit mailto:ankit.di...@eurostar.com> >; 
'Squid Users' mailto:squid-users@lists.squid-cache.org> >
Cc: SETHI Konica mailto:konica.se...@eurostar.com> >
Subject: RE: [squid-users] Squid memory consumption problem

 




 

Hey,

 

What 

Re: [squid-users] squid kerberos auth, acl note group

[Klaus Brandl]

> > But i think, we have a caching problem here, i found out, that the
> > group 
> > informations are only updated on a squid reconfigure.
> > 
> > And also the acl note group ... seems to be cached as long as squid
> > is 
> > restarted completely. I removed the configured group from the user,
> > but i could 
> > see this group still maching in the cache.log, also after a
> > reconfigure, when 
> > the auth_helper does not tell about this group any more.
> > 
> 
> The groups are attached to credentials which are attached to the TCP
> connection (TTL only as long as the connection is open) and a token
> replay cache for up to authenticate_ttl directive time (default 1
> hour).
> 
> Setting that TTL to something very short, eg:
> 
>   authenticate_ttl 10 seconds
> 
> ... and disabling connection keep-alive:
> 
>   client_persistent_connections off
> 
> ... should work around the cache for testing. At least on HTTP
> traffic.
> HTTPS traffic goes through the proxy as a single tunnel request - so
> the
> entire HTTPS session is just one request/response pair to Squid.
> 
> Amos
> ___
> squid-users mailing list
> squid-users@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

sorry again, but i still have this caching problem with the groups in
the note ACL. I have tested the options you suggested, but it takes no
effekt, the group is still matching until squid is completely
restarted. It looks like the note ACL is always appended only.
Or is there a way, to flush this content?

Regards

Klaus



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

Re: [squid-users] websockets through Squid

[Amos Jeffries]

On 19/10/20 11:07 am, Vieri wrote:
> 
> On Saturday, October 17, 2020, 10:36:47 PM GMT+2, Alex Rousskov wrote: 
> 
>> or due to some TLS error.
>> I filed bug #5084 
> 
>  Hi again,
> 
> Thanks for opening a bug report.
> 
> I don't want to add anything there myself because I wouldn't want to confuse 
> whoever might take this issue into account, but I'd like to comment on this 
> list that I've captured the traffic between Squid and the destination server.
> It's here:
> 
> https://drive.google.com/file/d/1WS7Y62Fng5ggXryzKGW1JOsJ16cyR0mg/view?usp=sharing
> 
> I can see a client hello, Server Hello Done, Cipher Spec, etc, but then it 
> starts over and over again.
> So, could it be a TLS issue as you hinted?
> 

I'm not seeing anything particularly unusual in there.

The many handshakes are all on different TCP connections, each is
successful, and followed by at least several "application data"
encrypted packets and a TLS connection closure alert before TCP FIN.


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