[squid-users] squid 3.2.0.19 compilation problem
Hi All, I am facing compilation problem with squid 3.2.0.19. This fails because of some changes in openssl header lhash.h (generally installs in /usr/icnlude/openssl/lhash.h). I used openssl 1.0.0 (OpenSSL 1.0.0-fips) for building squid. The lhash.h header has slightly different macros in openssl 1.0.0 and openssl 0.9.8. That is failing the build. I believe if we fix these macro calls, squid should compile without any problem. Most probably there won't be any issue with any other openssl APIs used by squid and squid hopefully works just fine with openssl 1.0.0 as well. My question here is, if anybody fixed the problem already and if squid works works with openssl 1.0.0 also. Below is the compilation error: certificate_db.cc: In member function ‘void Ssl::CertificateDb::load()’: certificate_db.cc:460: error: ‘index_serial_hash_LHASH_HASH’ was not declared in this scope certificate_db.cc:460: error: ‘index_serial_cmp_LHASH_COMP’ was not declared in this scope certificate_db.cc:463: error: ‘index_name_hash_LHASH_HASH’ was not declared in this scope certificate_db.cc:463: error: ‘index_name_cmp_LHASH_COMP’ was not declared in this scope certificate_db.cc: In member function ‘void Ssl::CertificateDb::deleteRow(const char**, int)’: certificate_db.cc:495: error: cannot convert ‘stack_st_OPENSSL_PSTRING*’ to ‘_STACK*’ for argument ‘1’ to ‘void* sk_delete(_STACK*, int)’ certificate_db.cc:504: error: ‘LHASH’ was not declared in this scope certificate_db.cc:504: error: ‘fieldIndex’ was not declared in this scope certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteInvalidCertificate()’: certificate_db.cc:525: error: cannot convert ‘stack_st_OPENSSL_PSTRING*’ to ‘const _STACK*’ for argument ‘1’ to ‘int sk_num(const _STACK*)’ certificate_db.cc:526: error: cannot convert ‘stack_st_OPENSSL_PSTRING*’ to ‘const _STACK*’ for argument ‘1’ to ‘void* sk_value(const _STACK*, int)’ certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteOldestCertificate()’: certificate_db.cc:549: error: cannot convert ‘stack_st_OPENSSL_PSTRING*’ to ‘const _STACK*’ for argument ‘1’ to ‘int sk_num(const _STACK*)’ certificate_db.cc:556: error: cannot convert ‘stack_st_OPENSSL_PSTRING*’ to ‘const _STACK*’ for argument ‘1’ to ‘void* sk_value(const _STACK*, int)’ certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteByHostname(const std::string)’: certificate_db.cc:573: error: cannot convert ‘stack_st_OPENSSL_PSTRING*’ to ‘const _STACK*’ for argument ‘1’ to ‘int sk_num(const _STACK*)’ certificate_db.cc:574: error: cannot convert ‘stack_st_OPENSSL_PSTRING*’ to ‘const _STACK*’ for argument ‘1’ to ‘void* sk_value(const _STACK*, int)’ Regards, Nipun Talukdar Bangalore India
[squid-users] Re: squid_kerb_auth High CPU load.
Markus Moeller huaraz at moeller.plus.com writes: Hi Viorel, What you mean with a list of high load sites ? Are you saying that the performance depends on which sites you are accessing via squid ? Regards Markus It's because of my pour english, I meant that I can easely simulate the situation without impacting my business. When I wrote high load I meant sites that users usualy access and squid are making a lot authentifications. Viorel
Re: [squid-users] squid 3.2.0.19 compilation problem
On 09.08.2012 20:04, nipun_mlist Assam wrote: Hi All, I am facing compilation problem with squid 3.2.0.19. This fails because of some changes in openssl header lhash.h (generally installs in /usr/icnlude/openssl/lhash.h). I used openssl 1.0.0 (OpenSSL 1.0.0-fips) for building squid. The lhash.h header has slightly different macros in openssl 1.0.0 and openssl 0.9.8. That is failing the build. I believe if we fix these macro calls, squid should compile without any problem. Most probably there won't be any issue with any other openssl APIs used by squid and squid hopefully works just fine with openssl 1.0.0 as well. My question here is, if anybody fixed the problem already and if squid works works with openssl 1.0.0 also. Could you please search your openssl .h files for the *exact* ABI version number and report back please. It should look like #define OPENSSL_VERSION_NUMBER ... Amos
Re: [squid-users] squid 3.2.0.19 compilation problem
Hi Amos, OPENSSL_VERSION_NUMBER is 0x1003L I replaced (in certificate_db.cc) #if OPENSSL_VERSION_NUMBER = 0x104fL with #if OPENSSL_VERSION_NUMBER = 0x1003L . Now I get the below problem: (compiler used is g++ (GCC) 4.4.4 20100726 (Red Hat 4.4.4-13) ) certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteInvalidCertificate()’: certificate_db.cc:523: error: invalid conversion from ‘void*’ to ‘const _STACK*’ certificate_db.cc:523: error: initializing argument 1 of ‘void* sk_value(const _STACK*, int)’ certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteOldestCertificate()’: certificate_db.cc:554: error: invalid conversion from ‘void*’ to ‘const _STACK*’ certificate_db.cc:554: error: initializing argument 1 of ‘void* sk_value(const _STACK*, int)’ certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteByHostname(const std::string)’: certificate_db.cc:571: error: invalid conversion from ‘void*’ to ‘const _STACK*’ certificate_db.cc:571: error: initializing argument 1 of ‘void* sk_value(const _STACK*, int)’ On Thu, Aug 9, 2012 at 4:22 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 09.08.2012 20:04, nipun_mlist Assam wrote: Hi All, I am facing compilation problem with squid 3.2.0.19. This fails because of some changes in openssl header lhash.h (generally installs in /usr/icnlude/openssl/lhash.h). I used openssl 1.0.0 (OpenSSL 1.0.0-fips) for building squid. The lhash.h header has slightly different macros in openssl 1.0.0 and openssl 0.9.8. That is failing the build. I believe if we fix these macro calls, squid should compile without any problem. Most probably there won't be any issue with any other openssl APIs used by squid and squid hopefully works just fine with openssl 1.0.0 as well. My question here is, if anybody fixed the problem already and if squid works works with openssl 1.0.0 also. Could you please search your openssl .h files for the *exact* ABI version number and report back please. It should look like #define OPENSSL_VERSION_NUMBER ... Amos -- Regards, Nipun
Re: [squid-users] squid 3.2.0.19 compilation problem
Fixed the compilation issue. I guess it is safe to use the check #if
OPENSSL_VERSION_NUMBER = 0x1003L instead. This check is there
in many files. I modified only certificate_db.cc. If we know the exact
openssl version from where these lhash, safestack etc. headers got
modified, then this check can be made more appropriate.
diff -ur squid-3.2.0.19/src/ssl/certificate_db.cc
squid-3.2.0.19_sslcompilefix/src/ssl/certificate_db.cc
--- squid-3.2.0.19/src/ssl/certificate_db.cc2012-08-02
05:14:34.0 -0700
+++ squid-3.2.0.19_sslcompilefix/src/ssl/certificate_db.cc
2012-08-09 05:25:19.362601312 -0700
@@ -450,7 +450,7 @@
corrupt = true;
// Create indexes in db.
-#if OPENSSL_VERSION_NUMBER = 0x104fL
+#if OPENSSL_VERSION_NUMBER = 0x1003L
if (!corrupt !TXT_DB_create_index(temp_db.get(), cnlSerial,
NULL, LHASH_HASH_FN(index_serial), LHASH_COMP_FN(index_serial)))
corrupt = true;
@@ -489,7 +489,7 @@
void Ssl::CertificateDb::deleteRow(const char **row, int rowIndex)
{
const std::string filename(cert_full + / + row[cnlSerial] + .pem);
-#if OPENSSL_VERSION_NUMBER = 0x104fL
+#if OPENSSL_VERSION_NUMBER = 0x1003L
sk_OPENSSL_PSTRING_delete(db.get()-data, rowIndex);
#else
sk_delete(db.get()-data, rowIndex);
@@ -497,7 +497,7 @@
const Columns db_indexes[]={cnlSerial, cnlName};
for (unsigned int i = 0; i countof(db_indexes); ++i) {
-#if OPENSSL_VERSION_NUMBER = 0x104fL
+#if OPENSSL_VERSION_NUMBER = 0x1003L
if (LHASH_OF(OPENSSL_STRING) *fieldIndex =
db.get()-index[db_indexes[i]])
lh_OPENSSL_STRING_delete(fieldIndex, (char **)row);
#else
@@ -518,9 +518,9 @@
return false;
bool removed_one = false;
-#if OPENSSL_VERSION_NUMBER = 0x104fL
+#if OPENSSL_VERSION_NUMBER = 0x1003L
for (int i = 0; i sk_OPENSSL_PSTRING_num(db.get()-data); ++i) {
-const char ** current_row = ((const char
**)sk_OPENSSL_PSTRING_value(db.get()-data, i));
+const char ** current_row = ((const char **)sk_value((const
_STACK *)(db.get()-data), i));
#else
for (int i = 0; i sk_num(db.get()-data); ++i) {
const char ** current_row = ((const char
**)sk_value(db.get()-data, i));
@@ -543,15 +543,15 @@
if (!db)
return false;
-#if OPENSSL_VERSION_NUMBER = 0x104fL
+#if OPENSSL_VERSION_NUMBER = 0x1003L
if (sk_OPENSSL_PSTRING_num(db.get()-data) == 0)
#else
if (sk_num(db.get()-data) == 0)
#endif
return false;
-#if OPENSSL_VERSION_NUMBER = 0x104fL
-const char **row = (const char
**)sk_OPENSSL_PSTRING_value(db.get()-data, 0);
+#if OPENSSL_VERSION_NUMBER = 0x1003L
+const char **row = (const char **)sk_value((const _STACK
*)(db.get()-data), 0);
#else
const char **row = (const char **)sk_value(db.get()-data, 0);
#endif
@@ -566,9 +566,9 @@
if (!db)
return false;
-#if OPENSSL_VERSION_NUMBER = 0x104fL
+#if OPENSSL_VERSION_NUMBER = 0x1003L
for (int i = 0; i sk_OPENSSL_PSTRING_num(db.get()-data); ++i) {
-const char ** current_row = ((const char
**)sk_OPENSSL_PSTRING_value(db.get()-data, i));
+const char ** current_row = ((const char **)sk_value((const
_STACK *)(db.get()-data), i));
#else
for (int i = 0; i sk_num(db.get()-data); ++i) {
const char ** current_row = ((const char
**)sk_value(db.get()-data, i));
Regards,
Nipun Talukdar
Bangalore
India
On Thu, Aug 9, 2012 at 4:39 PM, nipun_mlist Assam nipunml...@gmail.com wrote:
Hi Amos,
OPENSSL_VERSION_NUMBER is 0x1003L
I replaced (in certificate_db.cc)
#if OPENSSL_VERSION_NUMBER = 0x104fL
with
#if OPENSSL_VERSION_NUMBER = 0x1003L
.
Now I get the below problem: (compiler used is g++ (GCC) 4.4.4
20100726 (Red Hat 4.4.4-13) )
certificate_db.cc: In member function ‘bool
Ssl::CertificateDb::deleteInvalidCertificate()’:
certificate_db.cc:523: error: invalid conversion from ‘void*’ to ‘const
_STACK*’
certificate_db.cc:523: error: initializing argument 1 of ‘void*
sk_value(const _STACK*, int)’
certificate_db.cc: In member function ‘bool
Ssl::CertificateDb::deleteOldestCertificate()’:
certificate_db.cc:554: error: invalid conversion from ‘void*’ to ‘const
_STACK*’
certificate_db.cc:554: error: initializing argument 1 of ‘void*
sk_value(const _STACK*, int)’
certificate_db.cc: In member function ‘bool
Ssl::CertificateDb::deleteByHostname(const std::string)’:
certificate_db.cc:571: error: invalid conversion from ‘void*’ to ‘const
_STACK*’
certificate_db.cc:571: error: initializing argument 1 of ‘void*
sk_value(const _STACK*, int)’
On Thu, Aug 9, 2012 at 4:22 PM, Amos Jeffries squ...@treenet.co.nz wrote:
On 09.08.2012 20:04, nipun_mlist Assam wrote:
Hi All,
I am facing compilation problem with squid 3.2.0.19. This fails
because of some changes in openssl header lhash.h (generally installs
in /usr/icnlude/openssl/lhash.h).
I used openssl 1.0.0 (OpenSSL 1.0.0-fips) for building squid.
Re: [squid-users] squid 3.2.0.19 compilation problem
On 10/08/2012 12:35 a.m., nipun_mlist Assam wrote: Fixed the compilation issue. I guess it is safe to use the check #if OPENSSL_VERSION_NUMBER = 0x1003L instead. This check is there in many files. I modified only certificate_db.cc. If we know the exact openssl version from where these lhash, safestack etc. headers got modified, then this check can be made more appropriate. They were changed by the upstream OpenSSL project in version 1.0.0d (which uses ABI numbers 0x1040L to 0x104fL). It looks like somebody has patched your particular library 1.0.0 beta3 to back-port something? Amos Regards, Nipun Talukdar Bangalore India On Thu, Aug 9, 2012 at 4:39 PM, nipun_mlist Assam nipunml...@gmail.com wrote: Hi Amos, OPENSSL_VERSION_NUMBER is 0x1003L I replaced (in certificate_db.cc) #if OPENSSL_VERSION_NUMBER = 0x104fL with #if OPENSSL_VERSION_NUMBER = 0x1003L . Now I get the below problem: (compiler used is g++ (GCC) 4.4.4 20100726 (Red Hat 4.4.4-13) ) certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteInvalidCertificate()’: certificate_db.cc:523: error: invalid conversion from ‘void*’ to ‘const _STACK*’ certificate_db.cc:523: error: initializing argument 1 of ‘void* sk_value(const _STACK*, int)’ certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteOldestCertificate()’: certificate_db.cc:554: error: invalid conversion from ‘void*’ to ‘const _STACK*’ certificate_db.cc:554: error: initializing argument 1 of ‘void* sk_value(const _STACK*, int)’ certificate_db.cc: In member function ‘bool Ssl::CertificateDb::deleteByHostname(const std::string)’: certificate_db.cc:571: error: invalid conversion from ‘void*’ to ‘const _STACK*’ certificate_db.cc:571: error: initializing argument 1 of ‘void* sk_value(const _STACK*, int)’ On Thu, Aug 9, 2012 at 4:22 PM, Amos Jeffries squ...@treenet.co.nz wrote: On 09.08.2012 20:04, nipun_mlist Assam wrote: Hi All, I am facing compilation problem with squid 3.2.0.19. This fails because of some changes in openssl header lhash.h (generally installs in /usr/icnlude/openssl/lhash.h). I used openssl 1.0.0 (OpenSSL 1.0.0-fips) for building squid. The lhash.h header has slightly different macros in openssl 1.0.0 and openssl 0.9.8. That is failing the build. I believe if we fix these macro calls, squid should compile without any problem. Most probably there won't be any issue with any other openssl APIs used by squid and squid hopefully works just fine with openssl 1.0.0 as well. My question here is, if anybody fixed the problem already and if squid works works with openssl 1.0.0 also. Could you please search your openssl .h files for the *exact* ABI version number and report back please. It should look like #define OPENSSL_VERSION_NUMBER ... Amos -- Regards, Nipun
[squid-users] errors when building with ssl-crtd for CentOS 6
Hi
Apparently I'm having the exact same issue as Michael was in this thread:
http://www.squid-cache.org/mail-archive/squid-users/201204/0016.html
Differences are:
- I'm using 3.1.20
- I'm using CentOS 6.3 with openssl-1.0.0-20
- I'm building an RPM via mock
This is the configure section from the spec file:
%configure \
--libexecdir=%{_libdir}/squid \
--localstatedir=/var \
--datadir=%{_datadir}/squid \
--sysconfdir=%{_sysconfdir}/squid \
--with-logdir='$(localstatedir)/log/squid' \
--with-pidfile='$(localstatedir)/run/squid.pid' \
--disable-dependency-tracking \
--enable-arp-acl \
--enable-follow-x-forwarded-for \
--enable-auth=basic,digest,ntlm,negotiate \
--enable-basic-auth-helpers=LDAP,MSNT,NCSA,PAM,SMB,YP,getpwnam,multi-domain-NTLM,SASL,DB,POP3,squid_radius_auth
\
--enable-ntlm-auth-helpers=smb_lm,no_check,fakeauth \
--enable-digest-auth-helpers=password,ldap,eDirectory \
--enable-negotiate-auth-helpers=squid_kerb_auth \
--enable-external-acl-helpers=ip_user,ldap_group,session,unix_group,wbinfo_group
\
--enable-cache-digests \
--enable-cachemgr-hostname=localhost \
--enable-delay-pools \
--enable-epoll \
--enable-icap-client \
--enable-ident-lookups \
%ifnarch ppc64 ia64 x86_64 s390x
--with-large-files \
%endif
--enable-linux-netfilter \
--enable-referer-log \
--enable-removal-policies=heap,lru \
--enable-snmp \
--enable-ssl \
--enable-ssl-crtd \
--enable-storeio=aufs,diskd,ufs \
--enable-useragent-log \
--enable-wccpv2 \
--enable-esi \
--with-aio \
--with-default-user=squid \
--with-filedescriptors=65535 \
--with-maxfd=65535 \
--with-dl \
--with-openssl \
Errors (the first few lines):
certificate_db.cc: In member function 'void Ssl::CertificateDb::load()':
certificate_db.cc:404: error: 'index_serial_hash_LHASH_HASH' was not declared
in this scope
certificate_db.cc:404: error: 'index_serial_cmp_LHASH_COMP' was not declared in
this scope
certificate_db.cc:407: error: 'index_name_hash_LHASH_HASH' was not declared in
this scope
certificate_db.cc:407: error: 'index_name_cmp_LHASH_COMP' was not declared in
this scope
certificate_db.cc: In member function 'bool
Ssl::CertificateDb::deleteInvalidCertificate()':
certificate_db.cc:441: error: cannot convert 'stack_st_OPENSSL_PSTRING*' to
'const _STACK*' for argument '1' to 'int sk_num(const _STACK*)'
certificate_db.cc:442: error: cannot convert 'stack_st_OPENSSL_PSTRING*' to
'const _STACK*' for argument '1' to 'void* sk_value(const _STACK*, int)
I don't quite understand what Michael did to work-around it. I would just like
to know if this can be worked around given my environment and if so, how
exactly?
I'll be very sad if there's no possible way to have Squid 3.x w/ ssl-bump under
EL6.
Thanks
[squid-users] squid and authentication
Hi. I'm using squid for more than 10 years for now. I wrote a couple of articles about it. But there are still some basic things about it that I don't understand. Or, I don't know, some things about proxy authentication. I know I will look silly, but I still decided to ask. I decided to ask here, not because I'm sure it's a squid issue (I guess it's not) but because I think you guys have answered a lot of stupid questions why my authentication does'nt work. So. I imagine I have set up some authentication schemes. Basic, NTLM, doesn't matter. Imagine I have mozilla on some UNIX operating system. I launch it, I see that it's NTLM since it doesn't show the realm (and basic of course does) then I enter my credentials (I guess it's okay for unix, as mozilla on windows domain machine doesn't ask for it, so it must be some issue in NTLM/mozilla/samba or whatever), then it's okay until some point. But sooner or later Firefox (and Mozilla previously) will reask about my credentials. This happens a lot on UNIX OSes, and mostly with Mozilla. This happens though with Chrome, but not that often. What is it ? How long the credentials do stay in squid's cache ? I know about 'credentialsttl' for basic scheme, but there's no such option for NTLM. I've read the RFC 2617 and I dumped the HTTP sessions of client browsers with my proxy, but I didn't find the answer on a question why the authentication popup reappears - the RFC says nothing about reasking or keeping the explicit cache. One more question - why the browser cannot simply and silently resend the authentication, - all the browsers I've seen show the authentication popup again, so I think this is some common approach and not the browser developer conspiracy. Thanks. Eugene.
[squid-users] squid_ldap_group (Group into Group)
Hi squid users, I have a question about the helper squid_ldap_group whose don't find in the internet. I'm testing it and I noticed that it don't recognize groups inside group, but only read users inside group. The command I'm using is like this: external_acl_type AD_GROUP %LOGIN /usr/lib/squid3/squid_ldap_group -R -P -b dc=domain,dc=yyy -D cn=user,dc=domain,dc=yyy -w password -f ((objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=example,dc=domain,dc=yyy)) -h yyy.yyy.yyy.yyy Is there a way to squid_ldap_group to read the groups into the other group? Thanks in advance Rickifer Barros.
Re: [squid-users] squid 3.2 intercept and upstream proxy not working
On Thu, Aug 9, 2012 at 1:16 AM, Amos Jeffries squ...@treenet.co.nz wrote: I'm trying squid 3.2 (since I'll need some of the new features), but I'm having troubles using it in intercept mode, when used along with an upstream proxy. Which 3.2 release number please? that matters a LOT. Pardon; it was a 3.2.0.18; I'll try with the latest version as soon as possible and I'll post the results. BUT, ... checking your config file there is a bigger problem, and a relatively large amount of useless ACL checks ... Thank you very much for all the hints about the configuration! In 3.2 the default action when no cache_peer_access at all is configured, is to attempt to use the peer. I see. Maybe we have a bug in FIRSTUP_PARENT selection not checking the cache_peer_access properly. I'll do some tests in the next days, and let you know the results. What's the best debug_options to use, to analyze the FIRSTUP_PARENT selection? Thank you again. -- Davide Alberani davide.alber...@gmail.com [PGP KeyID: 0x465BFD47] http://www.mimante.net/
Re: [squid-users] Squid 3.2.0.19 beta is available
On 8/08/2012 11:51 p.m., Eliezer Croitoru wrote: On 8/7/2012 10:59 AM, Amos Jeffries wrote: mportant changes to note in this release: * As you should know CVE-2009-0801 security vulnerability protection was added in 3.2 series. Earlier betas attempted to protect peer caches as well as themselves, by blocking relay of untrusted requests until we could implement a safe relay. Due to time constraints this extra layer of peer protection has been REMOVED from 3.2 default builds. Interception cache proxies are themselves well protected against the vulnerability, but can indirectly poison any cache heirarchy they are integrated with. The -DSTRICT_HOST_VERIFY compile-time flag can be Sigh. Correction: -DSTRICT_ORIGINAL_DST is the flag name. defined in CXXFLAGS to re-enable this peer protection if desired. Its use is encouraged, but will result in problems for some popular configurations. ie ISP interception proxy gatewaying through a cache array, matrix of interception proxies as siblings. Use of the client destination IP (ORIGINAL_DST) is still preferred for untrusted requests, so if your proxy is backed by a firewall denial please ensure that the rules are REJECT rules rather than DROP for best performance. never_direct does not affect this routing preference as it does for DIRECT traffic. I want to verify because i'm a bit confused. can a intercepted request be forwarded to a cache_peer in any way? NOTE: I've spent a bit more time working it over and decided to drop that complication. New patch heading down for 3.2.0.20 later today. Amos
Re: [squid-users] squid_ldap_group (Group into Group)
Hi. On 10.08.2012 01:10, Rickifer Barros wrote: Hi squid users, I have a question about the helper squid_ldap_group whose don't find in the internet. I'm testing it and I noticed that it don't recognize groups inside group, but only read users inside group. The command I'm using is like this: external_acl_type AD_GROUP %LOGIN /usr/lib/squid3/squid_ldap_group -R -P -b dc=domain,dc=yyy -D cn=user,dc=domain,dc=yyy -w password -f ((objectclass=person)(sAMAccountName=%v)(memberof=cn=%a,ou=example,dc=domain,dc=yyy)) -h yyy.yyy.yyy.yyy Is there a way to squid_ldap_group to read the groups into the other group? Afaik, the only way to let the squid know about nested groups is to use a squid_kerb_ldap instead of the squid_ldap_group. Eugene.
Re: [squid-users] squid and authentication
On 10/08/2012 5:59 a.m., Eugene M. Zheganin wrote: Hi. I'm using squid for more than 10 years for now. I wrote a couple of articles about it. But there are still some basic things about it that I don't understand. Or, I don't know, some things about proxy authentication. I know I will look silly, but I still decided to ask. I decided to ask here, not because I'm sure it's a squid issue (I guess it's not) but because I think you guys have answered a lot of stupid questions why my authentication does'nt work. So. I imagine I have set up some authentication schemes. Basic, NTLM, doesn't matter. Yes it does. The model for thos two types of auth is *extremely* different, and affects things such as where credentials can be located, stored, or re-used. Which all have a great affect on the behaviour. Imagine I have mozilla on some UNIX operating system. I launch it, I see that it's NTLM since it doesn't show the realm (and basic of course does) then I enter my credentials (I guess it's okay for unix, as mozilla on windows domain machine doesn't ask for it, so it must be some issue in NTLM/mozilla/samba or whatever), then it's okay until some point. But sooner or later Firefox (and Mozilla previously) will reask about my credentials. This happens a lot on UNIX OSes, and mostly with Mozilla. This happens though with Chrome, but not that often. What is it ? How long the credentials do stay in squid's cache ? There are several caches involved. The OS (where Basic vs NTLM matters), Mozillas, Squids credential cache (where Basic vs NTLM matters), and Squid helper lookup cache, any backend authentication system caches (PAM, SASL, LDAP, etc may use some). As you can see the OS and Squid have scheme-specific limitations. I know about 'credentialsttl' for basic scheme, but there's no such option for NTLM. I've read the RFC 2617 and I dumped the HTTP sessions of client browsers with my proxy, but I didn't find the answer on a question why the authentication popup reappears - the RFC says nothing about reasking or keeping the explicit cache. One more question - why the browser cannot simply and silently resend the authentication, - all the browsers I've seen show the authentication popup again, so I think this is some common approach and not the browser developer conspiracy. They can. The popup is a browser GUI feature, there is no spec. It only means that Squid asked for credentials, and the browser did not know what to supply. That might be because the browser has several options available and can't choose. Or that somehow it believes the ones its got wont work. Or that it cant find any. The scheme-specific difference at the Squid end of the connection determine what happens there. Making a request (new connection - no credentials given): * NTLM credentials are requested from the browser and the multi-legged auth sequence started when it responds with stage-1 credentials. * Basic credentials a shared cache is used to only re-validate credentials after that credentialsttl timeout. Making a request (new connection - WITH new credentials given): * NTLM Squid checks the helper to verify the token and uses its output to determin whether to accept or continue the multi-legged auth sequence challenges. * Basic Squid checks the helper to verify the token. After validation the credentials get stored by Squid: * NTLM credentials are linked to a connection and last as long as that connection is alive. It is a form of caching, but without any fixed TTL. And does not permit TCP connection 1 to re-use credentials from connection 2 etc. * Basic credentials a shared cache of known credentials. Has a fixed TTL. Any request from any connection may replay trusted credentials and be accepted. The browser is required to re-send the auth token on every request regardless of scheme: * NTLM checks that it is unchanged from what got attached to the connection. Aborts the connection with an auth re-challenge if it has. * Basic does a full validation (short-circuited by the Squid users cache). Performing an auth re-challenge if it is unknown credentials. Each credentials has a TTL: * NTLM this is connection closure so they are just erased. * Basic re-validates the credentials token with the backend helper. The client/browser is only informed (via auth challenge) if the credentials fail to validate at this point. ... well when its working properly anyway. As you can see Squid only challenges until specific circumstances. One of these is happening when the browser logics end with a popup. Amos
