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

Tue Jan 24 21:11:05 UTC 2017

25.01.2017 2:50, Alex Rousskov пишет:
> 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
Sadly, but with this hack squid dies at request:

root @ khorne /patch # wget -S https://yandex.com/company/
--2017-01-25 02:53:58--  https://yandex.com/company/
Connecting to 127.0.0.1:3128... connected.

2017/01/25 02:53:51 kid1| Accepting SSL bumped HTTP Socket connections
at local=[::]:3128 remote=[::] FD 76 flags=9
FATAL: Received Segment Violation...dying.
2017/01/25 02:54:00 kid1| Closing HTTP(S) port [::]:3126
2017/01/25 02:54:00 kid1| Closing HTTP(S) port [::]:3127
2017/01/25 02:54:00 kid1| Closing HTTP(S) port [::]:3128
2017/01/25 02:54:00 kid1| storeDirWriteCleanLogs: Starting...
2017/01/25 02:54:00 kid1|     65536 entries written so far.
2017/01/25 02:54:00 kid1|    131072 entries written so far.
2017/01/25 02:54:01 kid1|    196608 entries written so far.
2017/01/25 02:54:01 kid1|    262144 entries written so far.
2017/01/25 02:54:01 kid1|    327680 entries written so far.
2017/01/25 02:54:01 kid1|    393216 entries written so far.
2017/01/25 02:54:01 kid1|    458752 entries written so far.
2017/01/25 02:54:01 kid1|    524288 entries written so far.
2017/01/25 02:54:01 kid1|    589824 entries written so far.
2017/01/25 02:54:01 kid1|   Finished.  Wrote 622687 entries.
2017/01/25 02:54:01 kid1|   Took 0.43 seconds (1438401.76 entries/sec).
CPU Usage: 1762.455 seconds = 1490.509 user + 271.946 sys
Maximum Resident Size: 0 KB
Page faults with physical i/o: 0

t at 1 (l at 1) program terminated by signal ABRT (Abort)
0xfffffd7ffe7c362a: __lwp_kill+0x000a:  jae      __lwp_kill+0x18       
[ 0xfffffd7ffe7c3638, .+0xe ]
(dbx)
where                                                                 
current thread: t at 1
=>[1] __lwp_kill(0x1, 0x6, 0xffffffffd1df63a0, 0xfffffd7ffe7c3f1e, 0x0,
0xfffffd7ffe823c80), at 0xfffffd7ffe7c362a
  [2] _thr_kill(), at 0xfffffd7ffe7bbf23
  [3] raise(), at 0xfffffd7ffe7681c9
  [4] abort(), at 0xfffffd7ffe746bc0
  [5] death(), at 0x6f463d
  [6] __sighndlr(), at 0xfffffd7ffe7bde26
  [7] call_user_handler(), at 0xfffffd7ffe7b26f2
  [8] sigacthandler(), at 0xfffffd7ffe7b291e
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [9] Ip::Qos::doTosLocalHit(), at 0x7d800e
  [10] clientReplyContext::doGetMoreData(), at 0x5d3009
  [11] clientReplyContext::identifyFoundObject(), at 0x5d323c
  [12] clientReplyContext::created(), at 0x5d3a45
  [13] StoreEntry::getPublicByRequest(), at 0x6cae49
  [14] clientStreamRead(), at 0x5edcc4
  [15] ClientHttpRequest::httpStart(), at 0x5d917e
  [16] ClientHttpRequest::processRequest(), at 0x5db570
  [17] ClientHttpRequest::doCallouts(), at 0x5dd1be
  [18] ACLChecklist::checkCallback(), at 0x76224a
  [19] ClientHttpRequest::doCallouts(), at 0x5ddd69
  [20] ClientRequestContext::clientStoreIdDone(), at 0x5e33bf
  [21] 0x5e3810(), at 0x5e3810
  [22] ACLChecklist::checkCallback(), at 0x76224a
  [23] ClientRequestContext::clientStoreIdStart(), at 0x5d8f78
  [24] ClientHttpRequest::doCallouts(), at 0x5dda59
  [25] ClientRequestContext::clientAccessCheckDone(), at 0x5e15b4
  [26] ClientRequestContext::clientAccessCheck2(), at 0x5e2318
  [27] ClientHttpRequest::doCallouts(), at 0x5dd8ec
  [28] ClientRequestContext::clientRedirectDone(), at 0x5e296b
  [29] 0x6b35dd(), at 0x6b35dd
  [30] 0x638393(), at 0x638393
  [31] AsyncCall::make(), at 0x7c0579
  [32] AsyncCallQueue::fireNext(), at 0x7c4cf3
  [33] AsyncCallQueue::fire(), at 0x7c508a
  [34] EventLoop::runOnce(), at 0x612229
  [35] EventLoop::run(), at 0x612348
  [36] SquidMain(), at 0x683518
  [37] main(), at 0x937f3c

>
> 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.
Very good. When it will be ready to use, or, at least, to test?
>
>
>> 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!
I think it's a necessary evil. As soon as we actually do attack, "Man in
the middle", whether to worry about lost virginity withnon-controlled
requests? No download intermediate certificates, we return to the local
and accompanied by a certificate-based hand. Here it is necessary to
decide - to go to smart or go to beautiful.

For smart is always remains sslproxy_foreign_intermediate_certs and all
the beauties of a manual tracking certificates. As I know from personal
experience, it is very entertaining organization of unlimited personal
time for proxy administrator. No girls, just clock-around support,
seriously.

So personally I'm willing to put up with uncontrollable requests to the
certificate stores.

Anyway, always exists an alternative. Either full automated
zero-administrated proxy appliance - or, handmade day-by-day entertained
and funny support.
>
>
> HTH,
>
> 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/222ffb70/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/222ffb70/attachment.sig>