[squid-users] Squid 4.x: Intermediate certificates downloader

[Yuri Voinov]

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.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170125/7c2df2e7/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170125/7c2df2e7/attachment.sig>