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

[Alex Rousskov]

On 01/24/2017 11:33 AM, Yuri Voinov wrote:

>> 1485279884.648      0 - TCP_DENIED/403 3574 GET
>> http://repository.certum.pl/ca.cer - HIER_NONE/- text/html;charset=utf-8


> http_access deny !Safe_ports

Probably does not match -- 80 is a safe port.


> # Instant messengers include
> include "/usr/local/squid/etc/acl.im.include"

I am guessing these do not match or are irrelevant.


> # Deny CONNECT to other than SSL ports
> http_access deny CONNECT !SSL_ports

Does not match. This is a GET request.


> # Only allow cachemgr access from localhost
> http_access allow localhost manager
> http_access deny manager

Probably do not match. This is not a cache manager request although I
have not checked how Squid identifies those exactly.


> http_access deny to_localhost

Does not match. The destination is not localhost.


> # Allow purge from localhost
> http_access allow PURGE localhost
> http_access deny PURGE

Do not match. This is a GET request, not PURGE.


> # Block torrent files
> acl TorrentFiles rep_mime_type mime-type application/x-bittorrent
> http_reply_access deny TorrentFiles

Does not match. There was no response [with an application/x-bittorrent
MIME type].


> # Windows updates rules
> http_access allow CONNECT wuCONNECT localnet
> http_access allow CONNECT wuCONNECT localhost

Do not match. This is a GET request, not CONNECT.


> http_access allow windowsupdate localnet
> http_access allow windowsupdate localhost

Probably do not match. The internal transaction is not associated with a
to-Squid connection coming from localnet or localhost.


> # Rule allowing access from local networks
> http_access allow localnet
> http_access allow localhost

Probably do not match. The internal transaction is not associated with a
to-Squid connection coming from localnet or localhost.


> # And finally deny all other access to this proxy
> http_access deny all

Matches!


> I have no idea, what can block access.

That much was clear from the time you asked the question. I bet your
last http_access rule that denies all other connection matches, but I
would still ask Squid. Squid knows why it blocks (or does not allow)
access. There are several ways to ask Squid, including increasing
debugging verbosity when reproducing the problem, adding the matching
ACL to the error message, using custom error messages for different
http_access deny lines, etc.

These methods are not easy, pleasant, quick, or human-friendly,
unfortunately, but you are a very capable sysadmin with more than enough
Squid knowledge to find the blocking directive/ACL, especially for a
problem that can be isolated to two HTTP transactions.

Once we know what directive/ACL blocks, we may be able to figure out a
workaround, propose a bug fix, etc. For example, if my guess is correct
-- the "deny all" rule has matched -- then you would need to add a rule
to allow internal requests, including the ones that fetch those missing
certificates.


HTH,

Alex.


> 25.01.2017 0:27, Alex Rousskov пишет:
>> On 01/24/2017 11:19 AM, Yuri Voinov wrote:
>>
>>> It is downloads directly via proxy from localhost:
>>> As I understand, downloader also access via localhost, right? 
>> This is incorrect. Downloader does not have a concept of an HTTP client
>> which sends the request to Squid so "via localhost" or "via any client
>> source address" does not apply to Downloader transactions. In other
>> words, there is no client [source address] for Downloader requests.
>>
>> Unfortunately, I do not know exactly what effect that lack of info has
>> on what ACLs (in part because there are too many of them and because
>> lack of info is often treated inconsistently by various ACLs). Thus, I
>> continue to recommend finding out which directive/ACL denied Downloader
>> access as the first step.
>>
>> Alex.
>>
>>
>>> 25.01.2017 0:16, Alex Rousskov пишет:
>>>> On 01/24/2017 10:48 AM, Yuri Voinov wrote:
>>>>
>>>>> It seems 4.0.17 tries to download certs but gives deny somewhere.
>>>>> However, same URL with wget via same proxy works
>>>>> Why?
>>>> Most likely, your http_access or similar rules deny internal download
>>>> transactions but allow external ones. This is possible, for example, if
>>>> your access rules use client information. Internal transactions (ESI,
>>>> missing certificate fetching, Cache Digests, etc.) do not have an
>>>> associated client.
>>>>
>>>> The standard denial troubleshooting procedure applies here: Start with
>>>> finding out which directive/ACL denies access. I am _not_ implying that
>>>> this is easy to do.
>