On 01/24/2017 02:11 PM, Yuri Voinov wrote: > 25.01.2017 2:50, Alex Rousskov пишет: >> 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 > Sadly, but with this hack squid dies at request: That death is unlikely to be related to the ACL hack itself IMO. You can test my theory by temporary replacing "generatedBySquid" with "all" on the http_access line. If Squid still dies with "all", please consider properly reporting the crash; it will probably continue to bite you even after the long-term solution (e.g., transaction_initiator ACL) is available. >> 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] > Very good. When it will be ready to use, or, at least, to test? I expect the first public implementation to be posted for squid-dev review within a week but this is not a promise. > So personally I'm willing to put up with uncontrollable requests to the > certificate stores. ... including any site pretending to be a certificate store. I respect that choice, but it must remain as a choice rather than hard-coded behavior IMO. I am sure that sooner or later somebody will come up with a "certificate" response that crashes Squid, and we do not want to leave the admins without a way to combat that attack vector. We could change Squid to ignore http_access and lots of other existing directives while adding an increasing number of new control directives dedicated to certificate fetching transactions, but I think that segregation approach would be a strategic mistake because there are too many potential segregation areas with partially overlapping and complex configuration requirements. It will get messy and too error-prone. Cheers, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
