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@1 (l@1) program terminated by signal ABRT (Abort) 0xfffffd7ffe7c362a: __lwp_kill+0x000a: jae __lwp_kill+0x18 [ 0xfffffd7ffe7c3638, .+0xe ] (dbx) where current thread: t@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. >
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
