[squid-users] 2.7.STABLE9 & Error with option deny_info from local requests

Amos Jeffries squid3 at treenet.co.nz
Mon Dec 1 09:32:10 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/11/2014 2:40 a.m., Mark Riede wrote:
> Hello,
> 
> I have a strange behavior with Squid 2.7.STABLE9 and local
> requests which should be intercept by the option deny_info.
> 

1) *Please* upgrade your Squid. 2.7 has been unsupported for more than 5
years now and is seriously out of date with modern web traffic needs.

2) "intercept" and how deny_info works are completely unrelated concepts.


> I am using Squid as a reverse proxy. I have configured a list of 
> subdomains (i.e. subdomain.domain.tld) in a file via the option 
> dstdomain, which will be forwarded to the defined cache peer.
> There is an additional list of domains (i.e. *.domain.tld) which
> match via wildcard to all other domains, which are not absolutely
> defined yet and will be forwarded to a custom error page via the
> option deny_info.
> 
> The problem is that requests forwarded to the ip of the server,
> i.e. 192.168.0.1, will be catched up by the option deny_info. But,
> when the request is forwarded to the ip of the localhost
> (127.0.0.1), the option deny_info will not match.

?? *all* traffic to the cache_peer is "forwarded to the ip 127.0.0.1"
since that IP *is* the cache_peer's IP.


127.0.0.1 (and ::1) are special purpose IP addresses. Traffic is not
permitted to go to/from it from a global-scope IP address. When you
send to/from a localhost IP then it is mandatory for the TCP system to
use the localhost IP as source.


> Now the strange behaviour is that requests to the ip of the
> localhost but with the destination domain subdomain.domain.tld will
> be answered successfully. I need a fix because clients get the
> custom error page for requests via http (NAT to 192.168.0.1) but
> not the same response via https (nginx to 127.0.0.1). I donĀ“t know
> where or how I can fix this problem or do more debugging.


Why is nginx not forwarding proper HTTP messages with the relevant
Host: header contents to Squid? the HTTP message syntax is no
different when sent over TLS port 443 as when sent over TCP port 80.

- From your description it sounds like nginx is sending to Squid
messages with URL https://127.0.0.1/* which cannot be expected to
exist in your list of acceptible domains.


Also, why are you not using Squid to receive and direct both HTTP and
HTTPS traffic to the relevant servers?
 Squid accepts port 443 traffic with an https_port directive just fine.


> 
> # Config http_access allow localhost

The above rule permits all traffic from 127.0.0.1 to go through this
proxy *no matter what*. From your description that would be all
traffic arriving from nginx **AND** any traffic you direct at
127.0.0.1 IP from any other software.

It is a very bad thing to do, particularly for a reverse-proxy. Remove
it and traffic from nginx (and yoru 127.0.0.1 tests) will start to
obey the other rules. Not a complete fix, but required for Squid to
work as you expect.

> acl foo dstdomain "/file" acl foo_deny dstdom_regex "/ file _deny" 
> http_access allow foo

When testing this ACL with a raw-IP Squid will lookup reverse-DNS of
the IPand compare the result with contents of /file.
Meaning 127.0.0.1 == "localhost" --> is "localhost" one of the peer
hosted domain names? should not be.

> cache_peer 127.0.0.1 parent 8080 0 no-query originserver name=srv1
login=PASS
> cache_peer_access srv1 allow foo cache_peer_access srv1 deny all 
> deny_info ERR_FOO foo_deny http_access deny foo_deny http_access
> deny all
<snip>

The rest of these rules match your intended behaviour of Squid.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUfDWaAAoJELJo5wb/XPRjfEYH/1KMTu400wRO0wmz6RURlUwB
6jVEqWGc+rYV1hvtjZe5PtvJW8nMxF6idP0SU2aj/GWoGmcusrq413sAsoQhwEYT
lGAlDhU08c6aQ5r7ZyNY9TMNip8OJS6NPYEWV07Nw34QuJcQXbHUEC9VTAjboQqa
VYfnrBZIbMXFY3wkdhGkyNm4m/Uz5scOZ2lKAVabhZ4wHEu/NVMYISD3mEIHNiT7
rLT9/dqZaj/KHn1Vb5Z31k3szija9ZMh2Gu6A5tg3TfpelBVrbCXFOzoHIJMN7es
eRScL64c2KZ1PMpTMrTUzq1ILcOIuXcVDSdcj610Tcp524u0ssQ1vteJqj8kFak=
=8Dhf
-----END PGP SIGNATURE-----


More information about the squid-users mailing list