25.01.2017 5:25, Alex Rousskov пишет: > 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. Yes, it also dies when I've changed final deny to allow all. I understand that is another bug (probably), but rught now has not enought time to build debug-enabled squid and reproduce death to backtrace. May be later. > > >>> 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. Excellent, will wait. > > >> So personally I'm willing to put up with uncontrollable requests to the >> certificate stores. > ... including any site pretending to be a certificate store. As I said, it's silly to cry about lost virginity by performing "Man of the middle." In addition, as I understand it, Squid takes the addresses of sites with certificates not from the Higher Mind and not from subspace - if my memory does not deceive, they are encoded in the certificates themselves, that is, a priori, be regarded as relatively safe. Also, it seemed to me, the intermediate certificates Squid sees as untrusted. > > 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. Exactly, I'm not talking about the absence of choice. Everyone should be able to meet their most foolish desire to scratch paranoia. > > 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. No-no-no, no segregation. Aliens are the same as homo primates. :-D Incidentally, when it was Squid configure simple and easy? :-! > > > Cheers, > > Alex. >
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
