On 01/24/2017 12:20 PM, Yuri Voinov wrote: > 25.01.2017 1:10, Alex Rousskov пишет: >> On 01/24/2017 11:33 AM, Yuri Voinov wrote: >>> http_access deny to_localhost >> Does not match. The destination is not localhost. > Yes, destination is squid itself. From squid to squid. No, not "to squid": The destination of the request is http://repository.certum.pl/ca.cer. As for the "from Squid" part, it is dangerous to think that way because, in most Squid contexts, "from" applies to the source of the request _received_ by Squid. In this case, there is no received request at all. So this transaction is _not_ "from Squid to Squid" in a sense that some other, regular transaction is "from user X to site Y". >>> # And finally deny all other access to this proxy >>> http_access deny all >> Matches! > But! This is recommended final deny rule, if I omit it - squid will adds > it silently by default, like normal firewall! Nobody is suggesting to omit this catch-all rule (which you have confirmed as matching in a follow-up email, thank you). The solution is to add a new "allow" rule (at least) above this last "deny all" one. In other words, your configuration is missing an http_access rule to allow internally-generated requests [to benign destinations]. > I don't know (on first look) special ACL rule to permit internal access > from squid to squid. A short-term hack: I have seen folks successfully solving somewhat similar problems using a localport ACL with an "impossible" value of zero. Please try this hack and update this thread if it works for you: > # Allow ESI, certificate fetching, Cache Digests, etc. internal requests > # XXX: Sooner or later, this unsupported hack will stop working! > acl generatedBySquid localport 0 > http_access allow generatedBySquid A possible long-term solution: Factory is working on adding support for the following new ACL which may help solve this and a few other problems: > acl aclname transaction_initiator initiator... > # Matches transaction's initiator [fast] > # Supported initiators are: > # esi: matches transactions fetching ESI resources > # certificate-fetching: matches transactions fetching > # a missing intermediate TLS certificate > # cache-digest: matches transactions fetching Cache Digests > # from a cache_peer > # icp: matches icp requests to peers > # icmp: matches icmp requests to peers > # asn: matches asns db requests > # internal: matches any of the above > # client: matches transactions containing an HTTP or FTP > # client request received at a Squid *_port > # all: matches all transactions > # Multiple initiators are ORed. Please note that these are draft specs that are subject to change. We may not be able to support many of the initiators listed above. We will support the certificate-fetching initiator though. > It looks squid blocks own internal access to itself, but > permits the same request from outside. As we discussed earlier, the destination here is not "Squid itself". Squid permits transaction with the same destination upon receiving a request from "outside" because your http_access rules permit such requests from "outside" while prohibiting transactions that are not based on "outside" requests. One aspect that complicates this problem in general is that we cannot simply allow internally-initiated transactions without an explicit admin permission because many of them, including the ones that fetch missing certificates, may go to completely arbitrary destinations (determined by origin servers, not users). Many admins care about where their Squid sends requests as much as they care about where their Squid is receiving the requests from! HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
