Re: [squid-users] Squid 5.1 for Debian Bullseye (amd64/i386/sources)
> -Oorspronkelijk bericht- > Van: squid-users > [mailto:squid-users-boun...@lists.squid-cache.org] Namens > Amos Jeffries > Verzonden: maandag 20 september 2021 23:48 > Aan: squid-users@lists.squid-cache.org > Onderwerp: Re: [squid-users] Squid 5.1 for Debian Bullseye > (amd64/i386/sources) > > On 21/09/21 1:03 am, L.P.H. van Belle wrote: > > And i have the Debian Bullseye packages also online. > > > > My changelog compaired to the Debian Unstable. > > > > squid (5.1-1.1bullseye1) bullseye; urgency=medium > > > > * Non-maintainer upload. > > * Used sources from squid-cache.org build : > squid-5.1-20210804-r1f9e52827 > > * Lowered previous version 5.1-2 back to 5.1-1 > > * d/patches, added fix-typos.patch found by Lintian. > > * d/watch, change http to https > > What URI are you using here exactly? > The www.squid-cache.org website does not provide https:// URLs. Ai, thats an "assumption" there was https .. (oeps).. And it does have it but gives : *.spd.co.il :-/ I'll revert that on next update. > > > > * d/*.tmp-file to *.tmp-files, Linitian predicated > warnings on tmp-file > > * d/rules switched lines 160-161, made the build more > consistent. > > - lowered this line: dh_installsystemd > -psquid-openssl --name=squid > > > > Would you be able to send me a copy of the diff/patch for > these please? > I will see how much can be pulled into Debian official fr the > v5.2 packages. Sure, i'll do that tomorrow. Greetz, Louis ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] hostHeaderVerify with SNI in interception environments
Hi again, FWIW, Factory is (slowly) working on an SslBump refactoring project that may address this bug. Thanks, I'll keep an eye on that. Andreas Zitat von Alex Rousskov : On 9/21/21 10:14 AM, Andreas Weigel wrote: Hi, sorry for the late response and the ambiguity in the initial post. That fact is unrelated to the concern being raised in this thread AFAICT: The concern is _not_ whether Squid verifies the target of the SNI-based CONNECT during step3. The concern is whether Squid verifies the target of the SNI-based CONNECT at all. Exactly. If splicing in step2, the SNI is validated (DNS lookup, comparing results with IP from client request). In that configuration, hostHeaderVerify is called twice, once at step1 (without any hosts, always passes) and once at step2 (with SNI, if present). If peeking in step2 and splicing in step3, the SNI is *not* validated in step2 -- hostHeaderVerify is only called once without any hostname at step1 in that case and that always passes. Glad we are on the same page. FWIW, Factory is (slowly) working on an SslBump refactoring project that may address this bug. I do not have a patch against official sources for you to try, but you can keep track of our progress at https://github.com/measurement-factory/squid/pull/108 Cheers, Alex. ___ 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] hostHeaderVerify with SNI in interception environments
Hi, sorry for the late response and the ambiguity in the initial post. That fact is unrelated to the concern being raised in this thread AFAICT: The concern is _not_ whether Squid verifies the target of the SNI-based CONNECT during step3. The concern is whether Squid verifies the target of the SNI-based CONNECT at all. Exactly. If splicing in step2, the SNI is validated (DNS lookup, comparing results with IP from client request). In that configuration, hostHeaderVerify is called twice, once at step1 (without any hosts, always passes) and once at step2 (with SNI, if present). If peeking in step2 and splicing in step3, the SNI is *not* validated in step2 -- hostHeaderVerify is only called once without any hostname at step1 in that case and that always passes. Andreas ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] hostHeaderVerify with SNI in interception environments
On 9/21/21 10:14 AM, Andreas Weigel wrote: > Hi, > > sorry for the late response and the ambiguity in the initial post. > >> That fact is unrelated to the concern being raised in this thread >> AFAICT: The concern is _not_ whether Squid verifies the target of the >> SNI-based CONNECT during step3. The concern is whether Squid verifies >> the target of the SNI-based CONNECT at all. > > Exactly. If splicing in step2, the SNI is validated (DNS lookup, > comparing results with IP from client request). In that configuration, > hostHeaderVerify is called twice, once at step1 (without any hosts, > always passes) and once at step2 (with SNI, if present). > > If peeking in step2 and splicing in step3, the SNI is *not* validated in > step2 -- hostHeaderVerify is only called once without any hostname at > step1 in that case and that always passes. Glad we are on the same page. FWIW, Factory is (slowly) working on an SslBump refactoring project that may address this bug. I do not have a patch against official sources for you to try, but you can keep track of our progress at https://github.com/measurement-factory/squid/pull/108 Cheers, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] got many messages after upgrade from 4.16 to 5.1: assertion failed: Transients.cc:221: "old == e"
On 9/21/21 2:31 AM, Dieter Bloms wrote: > I did an upgrade from squid 4.16 and got many messages like: assertion > failed: Transients.cc:221: "old == e" > and it seems, that the childs crash and restart: > > --snip-- > 2021/09/20 04:37:47 kid2| assertion failed: Transients.cc:221: "old == e" > current master transaction: master368193 > 2021/09/20 04:37:49 kid2| Set Current Directory to /var/cache/squid > 2021/09/20 04:37:49 kid2| Starting Squid Cache version 5.1 for > x86_64-pc-linux-gnu... > This proxy hasn't enabled sslbump and we don't use any cache directory. > We only cache in memory for performance reason. > > Is this a known issue or shall I open a bugreport ? It looks like you are suffering from bug 5134 which is awaiting more information from those who can reproduce it (and a volunteer to fix it): https://bugs.squid-cache.org/show_bug.cgi?id=5134 Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid 5.1: Kerberos: Unable to switch to basic auth with Edge - IE - Chrome
What i showed used kerberos, if that fails it used ntlm.. and you can add.. if
that fails use LDAP (basic auth) ..
This way, you support all of them.
if you going only for kerberos, that make sure you setup your krb5.conf
correctly..
A + PTR records, SPN/UPNs and yes, then you can run it fully without samba (
if your not haveing PTR, set rdns = no in krb5.conf )
Also, if you dont want the NTLM part, just remove the line :
--ntlm /usr/bin/ntlm_auth --allow-mschapv2 --helper-protocol=gss-spnego
--domain=ADDOM
on firefox, did you set this In Firefox, you have to go to the about:config
page and set the parameters
network.negotiate-auth.trusted-uris
network.automatic-ntlm-auth.trusted-uris
As far i can tell, what i see, is you didnt configure the browsers to use
kerberos.
Greetz,
Louis
Van: David Touzeau [mailto:da...@articatech.com]
Verzonden: dinsdag 21 september 2021 10:18
Aan: L.P.H. van Belle; squid-users@lists.squid-cache.org
Onderwerp: Re: [squid-users] squid 5.1: Kerberos: Unable to switch to basic
auth with Edge - IE - Chrome
Thanks Louis for this tips but we did not want to use NTLM as it is an old way.
It requires a samba on the Squid Box
As Amos said, this is most a browser (that using Microsoft API ) issue
The best way is to make these browsers replicating the correct Firefox
behavior.
Means swith to basic auth instead of trying this stupid NTLM method
Le 21/09/2021 à 09:38, L.P.H. van Belle a écrit :
in your smb.conf add # Added to enforced NTLM 2, must be set on all Samba
AD-DC's and the needed members. # This is used in combination with ntlm_auth
--allow-mschapv2 ntlm auth = mschapv2-and-ntlmv2-only In squid use: auth_param
negotiate program /usr/lib/squid/negotiate_wrapper_auth \ --kerberos
/usr/lib/squid/negotiate_kerberos_auth -k /etc/squid/krb5-squid-HTTP.keytab \
-s HTTP/proxy.fq.dn@my.realm.tld \ --ntlm /usr/bin/ntlm_auth
--allow-mschapv2 --helper-protocol=gss-spnego --domain=ADDOM If you connecting
for ldap.. Dont use -h 192.168.90.10 Uses -H ldaps://host.name.fq.dn Also push
the root-CA off the domain to pc's with GPO for example And in that GPO you can
set the parts you need to enable for the users/pcs to make it all work. But
your close, your almost there.. On thing i have not looked at myself yet,
ext_kerberos_ldap_group_acl
https://fossies.org/linux/squid/src/acl/external/kerberos_ldap_group/ext_kerberos_ldap_group_acl.8
Thats one i'll be using with squid 5.1, im still compiling everyting i need,
but then im setting It up, i'll document it and make and howto of it. Greetz,
Louis Van: squid-users [ MailScanner heeft een
e-mail met mogelijk een poging tot fraude gevonden van "lists.squid-cache.org"
mailto:squid-users-boun...@lists.squid-cache.org] Namens David Touzeau
Verzonden: dinsdag 21 september 2021 1:49 Aan:
squid-users@lists.squid-cache.org Onderwerp: [squid-users] squid 5.1: Kerberos:
Unable to switch to basic auth with Edge - IE - Chrome Hi all i have setup
Kerberos authentication with Windows 2019 domain using Squid 5.1 ( The Squid
version did not fix the issue - Tested 4.x and 5.x) In some cases, some
computers are not joined to the domain and ween need to allow authenticate on
Squid To allow this, Basic Authentication is defined in Squid and we expect
that browsers prompt a login to be authenticated and access to Internet But the
behavior is strange. On a computer outside the windows domain: Firefox is be
able to be successfully authenticated to squid using basic auth. Edge, Chrome
and IE still try ujsing NTLM method and are allways rejected with a 407 When
edge, chrome and IE try to establish a session, Squid claim 2021/09/21 01:17:27
kid1| ERROR: Negotiate Authentication validating user. Result: {result=BH,
notes={message: received type 1 NTLM token; }} This let us understanding that
these 3 browsers try NTLM instead of a Basic Authentication. I did not know why
these browsers using NTLM as they did not connected to the Windows domain Why
squid never get the Basic Authentication credentials. ? Did i miss something ?
Here it is my configuration. auth_param negotiate program
/lib/squid3/negotiate_kerberos_auth -r -s GSS_C_NO_NAME -k
/etc/squid3/PROXY.keytab auth_param negotiate children 20 startup=5 idle=1
concurrency=0 queue-size=80 on-persistent-overload=ERR auth_param negotiate
keep_alive on auth_param basic program /lib/squid3/basic_ldap_auth -v -R -b
"DC=articatech,DC=int" -D "administra...@articatech.int"
-W /etc/squid3/ldappass.txt -f
sAMAccountName=%s -v 3 -h 192.168.90.10 auth_param basic children 3 auth_param
basic realm Active Directory articatech.int auth_param basic credentialsttl
7200 seconds authenticate_ttl 3600 seconds authenticate_ip_ttl 1 seconds
authenticate_cache_garbage_interval 3600 seconds acl AUTHENTICATED proxy_auth
REQUIRED ___ squid-users mail
Re: [squid-users] squid 5.1: Kerberos: Unable to switch to basic auth with Edge - IE - Chrome
in your smb.conf add
# Added to enforced NTLM 2, must be set on all Samba AD-DC's and the needed
members.
# This is used in combination with ntlm_auth --allow-mschapv2
ntlm auth = mschapv2-and-ntlmv2-only
In squid use:
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth \
--kerberos /usr/lib/squid/negotiate_kerberos_auth -k
/etc/squid/krb5-squid-HTTP.keytab \
-s HTTP/proxy.fq.dn@my.realm.tld \
--ntlm /usr/bin/ntlm_auth --allow-mschapv2 --helper-protocol=gss-spnego
--domain=ADDOM
If you connecting for ldap.. Dont use -h 192.168.90.10
Uses -H ldaps://host.name.fq.dn
Also push the root-CA off the domain to pc's with GPO for example
And in that GPO you can set the parts you need to enable for the users/pcs to
make it all work.
But your close, your almost there..
On thing i have not looked at myself yet, ext_kerberos_ldap_group_acl
https://fossies.org/linux/squid/src/acl/external/kerberos_ldap_group/ext_kerberos_ldap_group_acl.8
Thats one i'll be using with squid 5.1, im still compiling everyting i need,
but then im setting
It up, i'll document it and make and howto of it.
Greetz,
Louis
Van: squid-users [mailto:squid-users-boun...@lists.squid-cache.org]
Namens David Touzeau
Verzonden: dinsdag 21 september 2021 1:49
Aan: squid-users@lists.squid-cache.org
Onderwerp: [squid-users] squid 5.1: Kerberos: Unable to switch to basic
auth with Edge - IE - Chrome
Hi all
i have setup Kerberos authentication with Windows 2019 domain using
Squid 5.1 ( The Squid version did not fix the issue - Tested 4.x and 5.x)
In some cases, some computers are not joined to the domain and ween
need to allow authenticate on Squid
To allow this, Basic Authentication is defined in Squid and we expect
that browsers prompt a login to be authenticated and access to Internet
But the behavior is strange.
On a computer outside the windows domain:
Firefox is be able to be successfully authenticated to squid using
basic auth.
Edge, Chrome and IE still try ujsing NTLM method and are allways
rejected with a 407
When edge, chrome and IE try to establish a session, Squid claim
2021/09/21 01:17:27 kid1| ERROR: Negotiate Authentication validating
user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
This let us understanding that these 3 browsers try NTLM instead of a
Basic Authentication.
I did not know why these browsers using NTLM as they did not connected
to the Windows domain
Why squid never get the Basic Authentication credentials. ?
Did i miss something ?
Here it is my configuration.
auth_param negotiate program /lib/squid3/negotiate_kerberos_auth -r -s
GSS_C_NO_NAME -k /etc/squid3/PROXY.keytab
auth_param negotiate children 20 startup=5 idle=1 concurrency=0
queue-size=80 on-persistent-overload=ERR
auth_param negotiate keep_alive on
auth_param basic program /lib/squid3/basic_ldap_auth -v -R -b
"DC=articatech,DC=int" -D "administra...@articatech.int"
-W /etc/squid3/ldappass.txt -f
sAMAccountName=%s -v 3 -h 192.168.90.10
auth_param basic children 3
auth_param basic realm Active Directory articatech.int
auth_param basic credentialsttl 7200 seconds
authenticate_ttl 3600 seconds
authenticate_ip_ttl 1 seconds
authenticate_cache_garbage_interval 3600 seconds
acl AUTHENTICATED proxy_auth REQUIRED
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
[squid-users] got many messages after upgrade from 4.16 to 5.1: assertion failed: Transients.cc:221: "old == e"
Hello, I did an upgrade from squid 4.16 and got many messages like: assertion failed: Transients.cc:221: "old == e" and it seems, that the childs crash and restart: --snip-- 2021/09/20 04:37:47 kid2| assertion failed: Transients.cc:221: "old == e" current master transaction: master368193 2021/09/20 04:37:49 kid2| Set Current Directory to /var/cache/squid 2021/09/20 04:37:49 kid2| Starting Squid Cache version 5.1 for x86_64-pc-linux-gnu... 2021/09/20 04:37:49 kid2| Service Name: squid 2021/09/20 04:37:49 kid2| Process ID 63991 2021/09/20 04:37:49 kid2| Process Roles: worker 2021/09/20 04:37:49 kid2| With 1048576 file descriptors available --snip-- This proxy hasn't enabled sslbump and we don't use any cache directory. We only cache in memory for performance reason. Is this a known issue or shall I open a bugreport ? -- regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] squid 5.1: Kerberos: Unable to switch to basic auth with Edge - IE - Chrome
Thanks amos !!
I think auth_schemes can be a workaround.
I will try it !
Le 21/09/2021 à 02:49, Amos Jeffries a écrit :
On 21/09/21 11:49 am, David Touzeau wrote:
When edge, chrome and IE try to establish a session, Squid claim
2021/09/21 01:17:27 kid1| ERROR: Negotiate Authentication validating
user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
This let us understanding that these 3 browsers try NTLM instead of a
Basic Authentication.
I did not know why these browsers using NTLM as they did not
connected to the Windows domain
Unlike Kerberos, NTLM does not require the machine to be connected to
a domain to have credentials. AFAIK the browser still has access to
the localhost user credentials for use in NTLM. Or the machine may
even be trying to use the Basic auth credentials as LM tokens with
NTLM scheme.
Why squid never get the Basic Authentication credentials. ?
That is a Browser decision. All Squid can do is offer the schemes it
supports and they have to choose which is used.
Did i miss something ?
With Squid-5 you can use the auth_schemes directive to workaround
issues like this.
Amos
___
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] squid 5.1: Kerberos: Unable to switch to basic auth with Edge - IE - Chrome
Thanks Louis for this tips but we did not want to use NTLM as it is an
old way.
It requires a samba on the Squid Box
As Amos said, this is most a browser (that using Microsoft API ) issue
The best way is to make these browsers replicating the correct Firefox
behavior.
Means swith to basic auth instead of trying this stupid NTLM method
Le 21/09/2021 à 09:38, L.P.H. van Belle a écrit :
in your smb.conf add
# Added to enforced NTLM 2, must be set on all Samba AD-DC's and the
needed members.
# This is used in combination with ntlm_auth --allow-mschapv2
ntlm auth = mschapv2-and-ntlmv2-only
In squid use:
auth_param negotiate program /usr/lib/squid/negotiate_wrapper_auth \
--kerberos /usr/lib/squid/negotiate_kerberos_auth -k
/etc/squid/krb5-squid-HTTP.keytab \
-s HTTP/proxy.fq.dn@my.realm.tld \
--ntlm /usr/bin/ntlm_auth --allow-mschapv2 --helper-protocol=gss-spnego
--domain=ADDOM
If you connecting for ldap.. Dont use -h 192.168.90.10
Uses -H ldaps://host.name.fq.dn
Also push the root-CA off the domain to pc's with GPO for example
And in that GPO you can set the parts you need to enable for the users/pcs to
make it all work.
But your close, your almost there..
On thing i have not looked at myself yet, ext_kerberos_ldap_group_acl
https://fossies.org/linux/squid/src/acl/external/kerberos_ldap_group/ext_kerberos_ldap_group_acl.8
Thats one i'll be using with squid 5.1, im still compiling everyting i need,
but then im setting
It up, i'll document it and make and howto of it.
Greetz,
Louis
Van: squid-users [mailto:squid-users-boun...@lists.squid-cache.org]
Namens David Touzeau
Verzonden: dinsdag 21 september 2021 1:49
Aan: squid-users@lists.squid-cache.org
Onderwerp: [squid-users] squid 5.1: Kerberos: Unable to switch to basic
auth with Edge - IE - Chrome
Hi all
i have setup Kerberos authentication with Windows 2019 domain using
Squid 5.1 ( The Squid version did not fix the issue - Tested 4.x and 5.x)
In some cases, some computers are not joined to the domain and ween
need to allow authenticate on Squid
To allow this, Basic Authentication is defined in Squid and we expect
that browsers prompt a login to be authenticated and access to Internet
But the behavior is strange.
On a computer outside the windows domain:
Firefox is be able to be successfully authenticated to squid using
basic auth.
Edge, Chrome and IE still try ujsing NTLM method and are allways
rejected with a 407
When edge, chrome and IE try to establish a session, Squid claim
2021/09/21 01:17:27 kid1| ERROR: Negotiate Authentication validating
user. Result: {result=BH, notes={message: received type 1 NTLM token; }}
This let us understanding that these 3 browsers try NTLM instead of a
Basic Authentication.
I did not know why these browsers using NTLM as they did not connected
to the Windows domain
Why squid never get the Basic Authentication credentials. ?
Did i miss something ?
Here it is my configuration.
auth_param negotiate program /lib/squid3/negotiate_kerberos_auth -r -s
GSS_C_NO_NAME -k /etc/squid3/PROXY.keytab
auth_param negotiate children 20 startup=5 idle=1 concurrency=0
queue-size=80 on-persistent-overload=ERR
auth_param negotiate keep_alive on
auth_param basic program /lib/squid3/basic_ldap_auth -v -R -b "DC=articatech,DC=int" -D
"administra...@articatech.int" -W
/etc/squid3/ldappass.txt -f sAMAccountName=%s -v 3 -h 192.168.90.10
auth_param basic children 3
auth_param basic realm Active Directory articatech.int
auth_param basic credentialsttl 7200 seconds
authenticate_ttl 3600 seconds
authenticate_ip_ttl 1 seconds
authenticate_cache_garbage_interval 3600 seconds
acl AUTHENTICATED proxy_auth REQUIRED
___
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
