[squid-users] Re: Squid not listening on any port
As long as you do not use parent proxy, no need for pinger. And, even in case of parent, pinger is nice to have. -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-not-listening-on-any-port-tp4667004p4667398.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Very slow initial reply
I have looked at the domain NS and it seems that 2 out of 4 are not responsive at all. If you are interested in clearing out the issue and more advanced dns related issues you can try bind-us...@lists.isc.org list. In the above list there are many dns administrators that can help and consult you on the next step to make the issue one of two: - gone(fixed locally) - fixed(fixed by the ns servers admins) Eliezer On 08/26/2014 09:20 PM, Cassiano Martin wrote: On my squid box it shows DNS failure. 014/08/26 15:15:09.243 kid1| ModEpoll.cc(139) SetSelect: FD 8, type=1, handler=1, client_data=0, timeout=0 2014/08/26 15:15:09.243 kid1| dns_internal.cc(1362) idnsRead: idnsRead: FD 8: received 55 bytes from 127.0.0.1:53 2014/08/26 15:15:09.243 kid1| dns_internal.cc(1169) idnsGrokReply: idnsGrokReply: QID 0xf689, -2 answers 2014/08/26 15:15:09.244 kid1| dns_internal.cc(1234) idnsGrokReply: idnsGrokReply: error Server Failure: The name server was unable to process this query. (2) 2014/08/26 15:15:09.244 kid1| dns_internal.cc(1092) idnsCallback: Merging DNS results www.lusitania.pt A has 3 RR, has -2 RR 2014/08/26 15:15:09.244 kid1| dns_internal.cc(1125) idnsCallback: Sending 3 (OK) DNS results to caller. 2014/08/26 15:15:09.244 kid1| ipcache.cc(498) ipcacheParse: ipcacheParse: 3 answers for 'www.lusitania.pt' 2014/08/26 15:15:09.244 kid1| ipcache.cc(556) ipcacheParse: ipcacheParse: www.lusitania.pt #0 212.55.134.4 2014/08/26 15:15:09.244 kid1| ipcache.cc(556) ipcacheParse: ipcacheParse: www.lusitania.pt #1 62.28.187.7 2014/08/26 15:15:09.245 kid1| client_side_request.cc(546) hostHeaderIpVerify: validate IP 62.28.187.7:80 non-match from Host: IP 212.55.134.4 2014/08/26 15:15:09.245 kid1| client_side_request.cc(541) hostHeaderIpVerify: validate IP 62.28.187.7:80 possible from Host: Thanks 2014-08-26 14:32 GMT-03:00 Bruno Guerreiro bruno.guerre...@ine.pt: Hello. Some of our user are complaning about very slow access to some sites. After some tests i've noticed that the time between squid receiving the request, and actually connecting to the site itself is very high. After this wait all the objects in the page are fetch rather quickly. I've tried upgrading to 3.4 but the issue persists. No auth in place, and the Squid server is connected to internet via full nat. Connecting directly from the server ou via some other proxy software, like nginx, works perfectly. Here are some of the sites (this are portuguese insurance companies): www.nseguros.pt www.lusitania.pt www.logo.pt Any ideas? Thanks in advance. Bruno Guerreiro DMSI/IT Instituto Nacional de Estatística Tel: 218440448 - Ext: 1657 Bruno Guerreiro DMSI/IT Instituto Nacional de Estatística Tel: 218440448 - Ext: 1657 Confidencialidade: Esta mensagem (e eventuais ficheiros anexos) é destinada exclusivamente às pessoas nela indicadas e tem natureza confidencial. Se receber esta mensagem por engano, por favor contacte o remetente e elimine a mensagem e ficheiros, sem tomar conhecimento do respectivo conteúdo e sem reproduzi-la ou divulgá-la. Confidentiality Warning: This e-mail message (and any attached files) is confidential and is intended solely for the use of the individual or entity to whom it is addressed. lf you are not the intended recipient of this message please notify the sender and delete and destroy all copies immediately.
[squid-users] Re: Squid not listening on any port
babajaga wrote As long as you do not use parent proxy, no need for pinger. And, even in case of parent, pinger is nice to have. I don't. So that's ok. Thanks! -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-not-listening-on-any-port-tp4667004p4667400.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Re: Squid not listening on any port
On 08/27/2014 09:31 AM, israelsilva1 wrote: babajaga wrote As long as you do not use parent proxy, no need for pinger. And, even in case of parent, pinger is nice to have. I don't. So that's ok. Thanks! Just make sure you have the sticky execution bit of a root user on the pinger binary file. If it's not set it would be the cause for it. (and as a side note: only root privileged user can use ICMP\PING unless used with sticky bit) Eliezer
Re: [squid-users] ICAP: entry went bad while waiting for adapted headers
Hey Maxim, You should better ask about it in squid-dev list rather then squid users list. More knowledge about ICAP internals is there. Eliezer On 08/26/2014 12:12 PM, Maxim Kulikov wrote: Hi All, I develop ICAP server for squid. Occasionally squid closes connection to my server, before all necessary data is written back to squid. This happens when answer on RESPMOD request to squid is sending. Following error found in log: 2014/08/20 13:56:20.063 kid1| Server.cc(265) abortOnBadEntry: entry is not Accepting! 2014/08/20 13:56:20.063 kid1| http.cc(2404) abortTransaction: aborting transaction for entry went bad while waiting for adapted headers; , this 0x7f653072e318 Issue reproduces randomly on different sites and different content types. Could any expert advice how to debug such an issue, and what could be a root cause. Thanks for your help. WBR, Maxim
Re: [squid-users] Very slow initial reply
Hello. Thanks for your reply. DNS was also my first thought, but what surprises me is that on the same server, nginx or direct are ok, but squid takes almost a minute. Also nslookup and dig work fast. And this happens everytime. But i'll look for DNS failures on the server Anyone has any other idea? Bruno Guerreiro DMSI/IT Instituto Nacional de Estatística Tel: 218440448 - Ext: 1657 - Original Message - From: Eliezer Croitoru elie...@ngtech.co.il To: squid-users@squid-cache.org Sent: Wednesday, 27 August, 2014 7:28:57 AM Subject: Re: [squid-users] Very slow initial reply I have looked at the domain NS and it seems that 2 out of 4 are not responsive at all. If you are interested in clearing out the issue and more advanced dns related issues you can try bind-us...@lists.isc.org list. In the above list there are many dns administrators that can help and consult you on the next step to make the issue one of two: - gone(fixed locally) - fixed(fixed by the ns servers admins) Eliezer On 08/26/2014 09:20 PM, Cassiano Martin wrote: On my squid box it shows DNS failure. 014/08/26 15:15:09.243 kid1| ModEpoll.cc(139) SetSelect: FD 8, type=1, handler=1, client_data=0, timeout=0 2014/08/26 15:15:09.243 kid1| dns_internal.cc(1362) idnsRead: idnsRead: FD 8: received 55 bytes from 127.0.0.1:53 2014/08/26 15:15:09.243 kid1| dns_internal.cc(1169) idnsGrokReply: idnsGrokReply: QID 0xf689, -2 answers 2014/08/26 15:15:09.244 kid1| dns_internal.cc(1234) idnsGrokReply: idnsGrokReply: error Server Failure: The name server was unable to process this query. (2) 2014/08/26 15:15:09.244 kid1| dns_internal.cc(1092) idnsCallback: Merging DNS results www.lusitania.pt A has 3 RR, has -2 RR 2014/08/26 15:15:09.244 kid1| dns_internal.cc(1125) idnsCallback: Sending 3 (OK) DNS results to caller. 2014/08/26 15:15:09.244 kid1| ipcache.cc(498) ipcacheParse: ipcacheParse: 3 answers for 'www.lusitania.pt' 2014/08/26 15:15:09.244 kid1| ipcache.cc(556) ipcacheParse: ipcacheParse: www.lusitania.pt #0 212.55.134.4 2014/08/26 15:15:09.244 kid1| ipcache.cc(556) ipcacheParse: ipcacheParse: www.lusitania.pt #1 62.28.187.7 2014/08/26 15:15:09.245 kid1| client_side_request.cc(546) hostHeaderIpVerify: validate IP 62.28.187.7:80 non-match from Host: IP 212.55.134.4 2014/08/26 15:15:09.245 kid1| client_side_request.cc(541) hostHeaderIpVerify: validate IP 62.28.187.7:80 possible from Host: Thanks 2014-08-26 14:32 GMT-03:00 Bruno Guerreiro bruno.guerre...@ine.pt: Hello. Some of our user are complaning about very slow access to some sites. After some tests i've noticed that the time between squid receiving the request, and actually connecting to the site itself is very high. After this wait all the objects in the page are fetch rather quickly. I've tried upgrading to 3.4 but the issue persists. No auth in place, and the Squid server is connected to internet via full nat. Connecting directly from the server ou via some other proxy software, like nginx, works perfectly. Here are some of the sites (this are portuguese insurance companies): www.nseguros.pt www.lusitania.pt www.logo.pt Any ideas? Thanks in advance. Bruno Guerreiro DMSI/IT Instituto Nacional de Estatística Tel: 218440448 - Ext: 1657 Bruno Guerreiro DMSI/IT Instituto Nacional de Estatística Tel: 218440448 - Ext: 1657 Confidencialidade: Esta mensagem (e eventuais ficheiros anexos) é destinada exclusivamente às pessoas nela indicadas e tem natureza confidencial. Se receber esta mensagem por engano, por favor contacte o remetente e elimine a mensagem e ficheiros, sem tomar conhecimento do respectivo conteúdo e sem reproduzi-la ou divulgá-la. Confidentiality Warning: This e-mail message (and any attached files) is confidential and is intended solely for the use of the individual or entity to whom it is addressed. lf you are not the intended recipient of this message please notify the sender and delete and destroy all copies immediately. Confidencialidade: Esta mensagem (e eventuais ficheiros anexos) � destinada exclusivamente �s pessoas nela indicadas e tem natureza confidencial. Se receber esta mensagem por engano, por favor contacte o remetente e elimine a mensagem e ficheiros, sem tomar conhecimento do respectivo conte�do e sem reproduzi-la ou divulg�-la. Confidentiality Warning: This e-mail message (and any attached files) is confidential and is intended solely for the use of the individual or entity to whom it is addressed. lf you are not the intended recipient of this message please notify the sender and delete and destroy all copies immediately.
Re: [squid-users] Very slow initial reply
On 27/08/2014 8:50 p.m., Bruno Guerreiro wrote: Hello. Thanks for your reply. DNS was also my first thought, but what surprises me is that on the same server, nginx or direct are ok, but squid takes almost a minute. Also nslookup and dig work fast. And this happens everytime. But i'll look for DNS failures on the server Anyone has any other idea? In Squid you can configure dns_timeout for how long it will wait in total for DNS results to come back. This will make an error response happen faster for this type of DNS error. As Eliezer mentioned, the fix is in your local DNS server config or the upstream domains DNS server config. * Your recursive DNS server used by Squid apparently has a long timeout on waits for a response from the domains NS-1 before moving on to its NS-2 etc. most of the actual lag you are seeing is coming from that. * The proper fix is for the upstream domain admin to fix their NS servers of course. If you contact them about which servers are having trouble that might get it fixed for everyone. Amos
Re: [squid-users] Re: Squid not listening on any port
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/08/2014 5:19 p.m., israelsilva1 wrote: israelsilva1 wrote babajaga wrote 1) Pinger exiting. You might try to disable pinger in squid.conf pinger_enable off Just for completeness: Pls, publish squid.conf, without comments. Anonymized. Disabled and it started listening! Thanks a lot... Now the question is: Why did pinger fail and should I bother fixing it? Most common reasons for fails are opening its sockets. Either the binary needs root owner:group and access to open the necessary sockets, or IPv6 socket for ICMPv6 fails to open on true dual-stack or split-stack operating systems. Amos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT/eiVAAoJELJo5wb/XPRjSRcIAL0DrCjgG49aBBD4JrjViFyn 0w/XqS+7qNHNhlGJX5ZfcV0V8yLpvJssNxa69WzIy50Tymb/mg68lozoUdhquof8 vH7rr/6fDxKw25Y5roahmHxNHiN9T5injq2JERqPRrd1kh/gpGA4Hul4ZDVgHtci ibmVLzwDjyRMXV82QgQ6IWJ+a11ZxgYtsODQqnBIdTcYIJFk3zzelc/1YDhWeDX/ P+cPtq2jNOrb9faTj/GZbspuzCOboHcC2V3+3js+iGjXuH2Ca2OVEckGJ69HUqfT uyaJ4Nm6uCyOLXhU1kpcwtyMiyZFrdB9vz80FixqV1A5jiM2xpvTQkzfrF0PlP8= =C54d -END PGP SIGNATURE-
Re: [squid-users] Re: kerberos_ldap_group stopped working with subdomains
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/08/2014 7:44 a.m., Markus Moeller wrote: Hi Pavel, Can you remove line 263 from support_krb5.cc and recompile ? It is fixed in the trunk for 3.5. The line is safe_free(principal_name); Regards Markus For the record, this fix is now in 3.4.7. Amos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT/elDAAoJELJo5wb/XPRjsk0H/irbDYvwbf8Asg/XWuxX1vK8 w0aiTACKtr/G3le2qpKz5eZLtG+6J5fznujN04wFDBdOmwfr4j+MWV8IcYO3Ij/y SfdsGIu7oRljQrBUMWop5Leyxg3kqYcQc+8316mlAgr4SdLeQTFN+8H+jpv2Rdv3 Ftxaf0/eVnnujnwnnU5UijVXJ5pur/IMeXv+raByCzFdRVJm4ooHxJYMwe5vYzgI ParSG9zlslZh3xR9Ae75Joo3R9S5PN6qnwiBTw4e73NP9m3aiDOyYHIOXIWEf2/Y BD4hlTm7j9sJWumyBh0b0VD2D05cYV7eVlZzOkqoBWsiTkBNMf4z5kEpmvenjt0= =RLho -END PGP SIGNATURE-
[squid-users] illegal instruction with 3.4.6 (no problem with 3.4.4)
squid exits with illegal instruction message Squid Cache: Version 3.4.6-20140826-r13168 configure options: '--disable-auth' '--disable-auto-locale' '--disable-cache-digests' '--disable-cpu-profiling' '--disable-debug-cbdata' '--disable-delay-pools' '--disable-devpoll' '--disable-ecap' '--disable-esi' '--disable-eui' '--disable-external-acl-helpers' '--disable-follow-x-forwarded-for' '--disable-forw-via-db' '--enable-gnuregex' '--disable-htcp' '--disable-icap-client' '--disable-ident-lookups' '--enable-internal-dns' '--disable-ipf-transparent' '--disable-ipfw-transparent' '--disable-ipv6' '--disable-leakfinder' '--disable-pf-transparent' '--disable-poll' '--disable-select' '--disable-snmp' '--disable-ssl' '--disable-stacktraces' '--disable-translation' '--disable-url-rewrite-helpers' '--disable-wccp' '--disable-wccpv2' '--disable-win32-service' '--disable-x-accelerator-vary' '--disable-icmp' '--disable-storeid-rewrite-helpers' '--enable-async-io' '--enable-disk-io' '--enable-epoll' '--enable-http-violations' '--enable-inline' '--enable-kill-parent-hack' '--enable-linux-netfilter' '--enable-log-daemon-helpers' '--enable-removal-policies' '--enable-storeio' '--enable-unlinkd' '--enable-x-accelerator-vary' '--enable-zph-qos' '--with-default-user=nobody' '--with-pthreads' '--with-included-ltdl' --enable-ltdl-convenience No problem with Squid Cache: Version 3.4.4-20140323-r13111 with the same compile options the cpu is cpu an Intel(R) Xeon(R) CPU E5345 @ 2.33GHz supporting: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm dtherm tpr_shadow It seems to be trying to use non existent instructions due to a cpu misdetection. -- Alfrenovsky
Re: [squid-users] illegal instruction with 3.4.6 (no problem with 3.4.4)
Please provide more details, like log output, or a coredump backtrace. Thanks 2014-08-27 11:44 GMT-03:00 Alfredo Rezinovsky alfr...@fing.uncu.edu.ar: squid exits with illegal instruction message Squid Cache: Version 3.4.6-20140826-r13168 configure options: '--disable-auth' '--disable-auto-locale' '--disable-cache-digests' '--disable-cpu-profiling' '--disable-debug-cbdata' '--disable-delay-pools' '--disable-devpoll' '--disable-ecap' '--disable-esi' '--disable-eui' '--disable-external-acl-helpers' '--disable-follow-x-forwarded-for' '--disable-forw-via-db' '--enable-gnuregex' '--disable-htcp' '--disable-icap-client' '--disable-ident-lookups' '--enable-internal-dns' '--disable-ipf-transparent' '--disable-ipfw-transparent' '--disable-ipv6' '--disable-leakfinder' '--disable-pf-transparent' '--disable-poll' '--disable-select' '--disable-snmp' '--disable-ssl' '--disable-stacktraces' '--disable-translation' '--disable-url-rewrite-helpers' '--disable-wccp' '--disable-wccpv2' '--disable-win32-service' '--disable-x-accelerator-vary' '--disable-icmp' '--disable-storeid-rewrite-helpers' '--enable-async-io' '--enable-disk-io' '--enable-epoll' '--enable-http-violations' '--enable-inline' '--enable-kill-parent-hack' '--enable-linux-netfilter' '--enable-log-daemon-helpers' '--enable-removal-policies' '--enable-storeio' '--enable-unlinkd' '--enable-x-accelerator-vary' '--enable-zph-qos' '--with-default-user=nobody' '--with-pthreads' '--with-included-ltdl' --enable-ltdl-convenience No problem with Squid Cache: Version 3.4.4-20140323-r13111 with the same compile options the cpu is cpu an Intel(R) Xeon(R) CPU E5345 @ 2.33GHz supporting: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm dtherm tpr_shadow It seems to be trying to use non existent instructions due to a cpu misdetection. -- Alfrenovsky
Re: [squid-users] illegal instruction with 3.4.6 (no problem with 3.4.4)
There's no log output, it just exists. No coredump either. strace output is useful ? Please provide more details, like log output, or a coredump backtrace. Thanks 2014-08-27 11:44 GMT-03:00 Alfredo Rezinovsky alfr...@fing.uncu.edu.ar: squid exits with illegal instruction message Squid Cache: Version 3.4.6-20140826-r13168 configure options: '--disable-auth' '--disable-auto-locale' '--disable-cache-digests' '--disable-cpu-profiling' '--disable-debug-cbdata' '--disable-delay-pools' '--disable-devpoll' '--disable-ecap' '--disable-esi' '--disable-eui' '--disable-external-acl-helpers' '--disable-follow-x-forwarded-for' '--disable-forw-via-db' '--enable-gnuregex' '--disable-htcp' '--disable-icap-client' '--disable-ident-lookups' '--enable-internal-dns' '--disable-ipf-transparent' '--disable-ipfw-transparent' '--disable-ipv6' '--disable-leakfinder' '--disable-pf-transparent' '--disable-poll' '--disable-select' '--disable-snmp' '--disable-ssl' '--disable-stacktraces' '--disable-translation' '--disable-url-rewrite-helpers' '--disable-wccp' '--disable-wccpv2' '--disable-win32-service' '--disable-x-accelerator-vary' '--disable-icmp' '--disable-storeid-rewrite-helpers' '--enable-async-io' '--enable-disk-io' '--enable-epoll' '--enable-http-violations' '--enable-inline' '--enable-kill-parent-hack' '--enable-linux-netfilter' '--enable-log-daemon-helpers' '--enable-removal-policies' '--enable-storeio' '--enable-unlinkd' '--enable-x-accelerator-vary' '--enable-zph-qos' '--with-default-user=nobody' '--with-pthreads' '--with-included-ltdl' --enable-ltdl-convenience No problem with Squid Cache: Version 3.4.4-20140323-r13111 with the same compile options the cpu is cpu an Intel(R) Xeon(R) CPU E5345 @ 2.33GHz supporting: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca lahf_lm dtherm tpr_shadow It seems to be trying to use non existent instructions due to a cpu misdetection. -- Alfrenovsky
Re: [squid-users] illegal instruction with 3.4.6 (no problem with 3.4.4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/08/2014 3:01 a.m., Alfredo Rezinovsky wrote: There's no log output, it just exists. No coredump either. strace output is useful ? Not really for this kind of thing. You wil have to run under a debugger, or enable core dumps in the OS settings for that. Some details on how to do that can be found at http://wiki.squid-cache.org/SquidFaq/BugReporting The big changes since 3.4.4 were an autotools version bump, and C++11 detection. You can try adding --disable-arch-native and see if it is the -march build options going bad in your compiler. If that does not work the problem is probably in the autotools scripts for detection of CPU type. That would be an autotools (autoconf) project problem. Another thing possible is if you auto-apply patches which are now applying as reversed that can make them actually cause a problem. Amos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT/f60AAoJELJo5wb/XPRjH0sH/R93AB3D/SSP5hQZIooGzUzY 9eSD60WaSZVraCfn5oVaqDdKNz+8RLoh4mvlnvwz9S3p8AmH7NeeYb0mmrtV5/fr jT2x5QwXofdQGO7l2zE5sPcblQ+C+u5Tplof/AENcTqIjXzYV73Tt+YF35zZj0rR dvO7woX0y2k6jk/dE0o4BtRG0l2qW76QOFcrd/Yqmv0l7wZAgftzgD/D4sYcKUMp Pio08BGOjRYMk+F4T1ZBvvvBYB21LMnA5j86oZ7nHRpyeZiQ9HhsEOnb0fu34pe9 0XwNO8f9wWXvXk+97tYECD99jbMb8DEBRPOgFq5j83Ym6RPJxy0fSPxVNzYy8GM= =O7Ur -END PGP SIGNATURE-
[squid-users] Squid 3.3.13 is available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Squid HTTP Proxy team is very pleased to announce the availability of the Squid-3.3.13 release! This release is a security fix release resolving a major vulnerability found in the prior Squid releases. REMINDER: This and older releases are already deprecated by Squid-3.4 availablility. The major changes to be aware of: * CVE-2014-3609 : SQUID-2014:2 Denial of service in request processing http://www.squid-cache.org/Advisories/SQUID-2014_2.txt This vulnerability allows any client who is allowed to use the proxy to perform a denial of service attack on Squid. This issue is particularly impacting reverse-proxy installations. A simple squid.conf workaround is available for quick use and those unable to upgrade. See the Advisory notice for details. See the ChangeLog for the full list of changes in this and earlier releases. All users are urged to upgrade as soon as possible. Please remember to run squid -k parse when testing upgrade to a new version of Squid. It will audit your configuration files and report any identifiable issues the new release will have in your installation before you press go. We are still removing the infamous Bungled Config halting points and adding checks, so if something is not identified please report it. Please refer to the release notes at http://www.squid-cache.org/Versions/v3/3.3/RELEASENOTES.html when you are ready to make the switch to Squid-3.3 Upgrade tip: squid -k parse is starting to display even more useful hints about squid.conf changes. This new release can be downloaded from our HTTP or FTP servers http://www.squid-cache.org/Versions/v3/3.3/ ftp://ftp.squid-cache.org/pub/squid/ ftp://ftp.squid-cache.org/pub/archive/3.3/ or the mirrors. For a list of mirror sites see http://www.squid-cache.org/Download/http-mirrors.html http://www.squid-cache.org/Download/mirrors.html If you encounter any issues with this release please file a bug report. http://bugs.squid-cache.org/ Amos Jeffries -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT/gnhAAoJELJo5wb/XPRjxbQH/j8yDWmRKHoeEttXmci9vXUY 2HMUloJjC7AMDkMWM9CaPebwNsLeTQEmtoQ5DtnxhPZA/QcXCf+sjWQNv+Kyrpx8 f6psq3jMVXn+xgDHeDd1EvBa+a3XqYkRp7tKxz4IDsIGxfja5L7W39PGV6ErHlMa b4U674R7GJM9xLpj6sfeKWoW2xhv7620i7Zk8ZZVpYH/mwgxW7TRjYmev4YVnixC XG+f0ExseElc+fNvvc2bGsXKgQBAy1S1DjxnagQ+FrIEyT4R9nUge4YC6G0JPmbW 73XMx9blJp5jby7WgKD+YLufJbJAY4TdT6mETN4TwYecaoy/2vZJ/wxW/6TLLis= =kP6w -END PGP SIGNATURE-
[squid-users] [ADVISORY] SQUID-2014:2 Denial of service in request processing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 __ Squid Proxy Cache Security Update Advisory SQUID-2014:2 __ Advisory ID:SQUID-2014:2 Date: August 28, 2014 Summary:Denial of service in request processing Affected versions: Squid 3.x - 3.3.12 Squid 3.4 - 3.4.6 Fixed in version: Squid 3.3.13, 3.4.7 __ http://www.squid-cache.org/Advisories/SQUID-2014_2.txt http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3609 __ Problem Description: Due to incorrect input validation in request parsing Squid is vulnerable to a denial of service attack when processing Range requests. __ Severity: This problem allows any trusted client to perform a denial of service attack on the Squid service. __ Updated Packages: This bug is fixed by Squid version 3.3.13 and 3.4.7 In addition, patches addressing this problem for stable releases can be found in our patch archives: Squid 3.0: http://www.squid-cache.org/Versions/v3/3.0/changesets/squid-3.0-9201.patch Squid 3.1: http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-10488.patch Squid 3.2: http://www.squid-cache.org/Versions/v3/3.2/changesets/squid-3.2-11828.patch Squid 3.3: http://www.squid-cache.org/Versions/v3/3.3/changesets/squid-3.3-12680.patch Squid 3.4: http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13168.patch If you are using a prepackaged version of Squid then please refer to the package vendor for availability information on updated packages. __ Determining if your version is vulnerable: Squid-3.x: All Squid-3.x versions up to and including 3.3.12 are vulnerable to the problem. Squid-3.4: All Squid-3.4 versions up to and including 3.4.6 are vulnerable to the problem. __ Workaround: Add the following access control lines to squid.conf above any http_access allow lines: acl validRange req_header Range \ ^bytes=([0-9]+\-[0-9]*|\-[0-9]+)(,([0-9]+\-[0-9]*|\-[0-9]+))*$ acl validRange req_header Request-Range \ ^bytes=([0-9]+\-[0-9]*|\-[0-9]+)(,([0-9]+\-[0-9]*|\-[0-9]+))*$ http_access deny !validRange __ Contact details for the Squid project: For installation / upgrade support on binary packaged versions of Squid: Your first point of contact should be your binary package vendor. If you install and build Squid from the original Squid sources then the squid-users@squid-cache.org mailing list is your primary support point. For subscription details see http://www.squid-cache.org/Support/mailing-lists.html. For reporting of non-security bugs in the latest release the squid bugzilla database should be used http://bugs.squid-cache.org/. For reporting of security sensitive bugs send an email to the squid-b...@squid-cache.org mailing list. It's a closed list (though anyone can post) and security related bug reports are treated in confidence until the impact has been established. __ Credits: The vulnerability was discovered by Matthew Daley. __ Revision history: 2014-08-26 11:54 GMT Initial Report 2014-08-26 18:28 GMT CVE Assignment 2014-08-27 15:18 GMT Patches and Packages Released __ END -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT/gntAAoJELJo5wb/XPRjgDwIAJoMyiWY2wMpThWkag6WkqUP Tn+hsLRc6cBORwyOZNyYSloZh8v4C8WKfl96wTew1sLSZrCrHDx1iLXozJeSRLiW Mnzv9wN7MdmyhRou4FEspuQj8IjenvSrk4Eg56+vc6g3caUeVHuCzmNdjmPss6q0 3OxFbzIpx69xakhHLXQEG+3LmPPZMz/479mlrb8AsJ2t/4v0GXRyd8KrhL323EFS ZZCk6o/rZNOnTOVEcABbwWBsvaA1d2WMVSJ9s3adPT9c32n6OyX4UPm8sijGLDkT mAKk5+3t+nExpaSFjk/Q+708fHR6Iatqgf2UqWWXYcMkQKKdETxFXXwKx6zT7pA= =lBYi -END PGP SIGNATURE-
[squid-users] Squid 3.4.7 is available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Squid HTTP Proxy team is very pleased to announce the availability of the Squid-3.4.7 release! This release is a security and bug fix release resolving a major vulnerability and several other issues found in the prior Squid releases. The major changes to be aware of: * CVE-2014-3609 : SQUID-2014:2 Denial of service in request processing http://www.squid-cache.org/Advisories/SQUID-2014_2.txt This vulnerability allows any client who is allowed to use the proxy to perform a denial of service attack on Squid. This issue is particularly impacting reverse-proxy installations. A simple squid.conf workaround is available for quick use and those unable to upgrade. See the Advisory notice for details. * Various SSL-bump certificate mimic errors These bugs show up most notably for users of Firefox complaining about a sec_error_inadequate_key_usage error. They are caused by Squid generating a fake certificate with the wrong X.509 version details for the TLS extensions being mimiced in that certificate. * Bug #4080: worker hangs when client identd is not responding This bug shows up as the Squid worker process hanging. It occurs only when IDENT protocol is enabled and the client identd fails to respond. IDENT protocol use may be enabled either for access control or logging purposes. * Portability improvements As always we seek to support as many popular operating systems as possible. This release contains several updates to fix build issues and increase the supported operating systems and CPU architectures. All users of Squid are urged to upgrade to this release as soon as possible. See the ChangeLog for the full list of changes in this and earlier releases. Please refer to the release notes at http://www.squid-cache.org/Versions/v3/3.4/RELEASENOTES.html when you are ready to make the switch to Squid-3.4 Upgrade tip: squid -k parse is starting to display even more useful hints about squid.conf changes. This new release can be downloaded from our HTTP or FTP servers http://www.squid-cache.org/Versions/v3/3.4/ ftp://ftp.squid-cache.org/pub/squid/ ftp://ftp.squid-cache.org/pub/archive/3.4/ or the mirrors. For a list of mirror sites see http://www.squid-cache.org/Download/http-mirrors.html http://www.squid-cache.org/Download/mirrors.html If you encounter any issues with this release please file a bug report. http://bugs.squid-cache.org/ Amos Jeffries -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT/gq3AAoJELJo5wb/XPRjUIUH/AgC2Z2H4ziAxLnwWP9Z2Br5 Y1gAbN1I+wYwuGDGoFrvuHX49rVKWt0N6+i8bw0dwJgR+lBqqCS87EUdcDiALvDh RqspxZBxh4AZE1SSJJx/EDLlT5q653okxQJ2b16/YNreEMp3W0LEpQMgEjoNZ+mn 4FZz79XuMOdl+oridn419jRb6c5p4mPlEAoPe4AVyMylvEg3PTGnlkckY9oAtxqT VWwsAy6ZIvM3hp0QECqJVOcEqfmnQ6tVvvebPgQjXOlAYCS4sGnDtUPMu3yFEDYa vDKy77LTvI1DF4zXFsAUxPonY4HBO66ekkWa9K0MENrrXxUOZnl+6E5JtziFL7g= =xKq5 -END PGP SIGNATURE-
Re: [squid-users] Re: kerberos_ldap_group stopped working with subdomains
Thanks!
I think I've noticed a typo in squid 3.4.7
# diff -u helpers/external_acl/kerberos_ldap_group/support_ldap.cc.orig
helpers/external_acl/kerberos_ldap_group/support_ldap.cc
--- helpers/external_acl/kerberos_ldap_group/support_ldap.cc.orig
2014-08-27 21:37:01.0 +0400
+++ helpers/external_acl/kerberos_ldap_group/support_ldap.cc
2014-08-27 21:37:15.0 +0400
@@ -811,7 +811,7 @@
#endif
}
-if (kc (!margs-lurl || !margs-luser | !margs-lpass)) {
+if (kc (!margs-lurl || !margs-luser || !margs-lpass)) {
/*
* If Kerberos fails and no url given exit here
*/
True?
2014-08-27 18:20 GMT+04:00 Amos Jeffries squ...@treenet.co.nz:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/08/2014 7:44 a.m., Markus Moeller wrote:
Hi Pavel,
Can you remove line 263 from support_krb5.cc and recompile ? It is
fixed in the trunk for 3.5.
The line is safe_free(principal_name);
Regards Markus
For the record, this fix is now in 3.4.7.
Amos
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJT/elDAAoJELJo5wb/XPRjsk0H/irbDYvwbf8Asg/XWuxX1vK8
w0aiTACKtr/G3le2qpKz5eZLtG+6J5fznujN04wFDBdOmwfr4j+MWV8IcYO3Ij/y
SfdsGIu7oRljQrBUMWop5Leyxg3kqYcQc+8316mlAgr4SdLeQTFN+8H+jpv2Rdv3
Ftxaf0/eVnnujnwnnU5UijVXJ5pur/IMeXv+raByCzFdRVJm4ooHxJYMwe5vYzgI
ParSG9zlslZh3xR9Ae75Joo3R9S5PN6qnwiBTw4e73NP9m3aiDOyYHIOXIWEf2/Y
BD4hlTm7j9sJWumyBh0b0VD2D05cYV7eVlZzOkqoBWsiTkBNMf4z5kEpmvenjt0=
=RLho
-END PGP SIGNATURE-
[squid-users] source address ip spoofing
Hello Squid Dev. Team and Users, I need your advice on a Squid deployment scenario. We have deployed on our network a physical machine with Squid 2.7 listening on port 8080. Proxy Auto-Discovery on our users browsers is able to get activated by a wpad.dat file which transparently redirects our users HTTP requests to our Proxy Server. The way our Proxy Server works now is by hiding the IP address of users getting directed to our machine. Question is... can we have our Proxy Server working in the same deployment scenario but doing Source IP Address Spoofing and making content requests that do not hide users IP(s)? Thank you, Julian -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/source-address-ip-spoofing-tp4667417.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] source address ip spoofing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/08/2014 7:28 a.m., Julian wrote: Hello Squid Dev. Team and Users, I need your advice on a Squid deployment scenario. We have deployed on our network a physical machine with Squid 2.7 listening on port 8080. Proxy Auto-Discovery on our users browsers is able to get activated by a wpad.dat file which transparently redirects our users HTTP requests to our Proxy Server. The way our Proxy Server works now is by hiding the IP address of users getting directed to our machine. Question is... can we have our Proxy Server working in the same deployment scenario but doing Source IP Address Spoofing and making content requests that do not hide users IP(s)? The clients original IP is transmitted in the X-Forwarded-For HTTP header by default. Unless your proxy admin has configured that header to be deleted or off your appliction should be able to find it there. http://www.squid-cache.org/Doc/config/forwarded_for/ Amos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT/qEWAAoJELJo5wb/XPRjHGgH/j/UPCkhYft8jpsvEDd9JBH0 r220fBdx+ixw6EnKyhFKV9lt95tSOlm6x4lmEwg1fwl+5oqobHP6/qYansUKHiiG ucFq6MIWArC2NBuKubD11yLlbaAV4KDeY8kmwKbqQxnOUQ5bYkkbf09hpREBXtKs oXq5/IUUhWe0/Kl8orRiJkwITZwiNNVFUsXZKCkdlHB8Wx6rfjmv+llEgUcfwQn/ OIdBXw3GFsp+YyFFgACIMV5kuygZheO4dZY7PRzYM8FwpIclmpubu2GDk8Pql1Tj L3IsryG34MjQRp6UVpVvcmOUAIZ0V1MhZOKpztZfy4Bbs6UrjnjzbuQK/bTLCFA= =frAw -END PGP SIGNATURE-
