Squid 4.x: Intermediate certificates downloader

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Squid 4.x: Intermediate certificates downloader

Yuri Voinov
Hi, gents.

I have some stupid questions about subject.

1. How does it work? I.e., where downloaded certs stored, how it
handles, does it saves anywhere to disk? Because of this feature is
completely undocumented and it did not follow from the source code.

2. How this feature is related to sslproxy_foreign_intermediate_certs,
how it can interfere with it? Because of this one also completely
undocunemted and nobody has enough unlimited free time to study complete
sources of squid to understand features.

If somebody knows answers, please, I ask them to voice it.

Release notes contains nothing about this feature. Wiki contains only
one mention in passing that this functionality exists in principle.

Thanks in advance.




_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Alex Rousskov
On 01/23/2017 04:28 AM, Yuri wrote:

> 1. How does it work?

My response below and the following commit message might answer some of
your questions:

    http://bazaar.launchpad.net/~squid/squid/5/revision/14769

> I.e., where downloaded certs stored, how it
> handles, does it saves anywhere to disk?

Missing certificates are fetched using HTTP[S]. Certificate responses
should be treated as any other HTTP[S] responses with regard to caching.
For example, if you have disk caching enabled and your caching rules
(including defaults) allow certificate response caching, then the
response should be cached. Similarly, the cached certificate will
eventually be evicted from the cache following regular cache maintenance
rules. When that happens, Squid will try to fetch the certificate again
(if it becomes needed again).


> 2. How this feature is related to sslproxy_foreign_intermediate_certs,
> how it can interfere with it?

AFAICT by looking at the code, Squid only downloads certificates that
Squid is missing when trying to build a complete certificate chain for a
given server connection. Any sslproxy_foreign_intermediate_certs are
used as needed during the chain building process (i.e., they are _not_
"missing").


> Release notes contains nothing about this feature. Wiki contains only
> one mention in passing that this functionality exists in principle.

I agree that this feature lacks documentation. This is, in part, because
the feature has no configuration options that normally force developers
to document at least some of the code logic. We should add a few words
about it to sslproxy_foreign_intermediate_certs documentation.


FWIW, we are also adding an ACL to identify internal transactions that
fetch missing certificates.


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov


23.01.2017 23:31, Alex Rousskov пишет:

> On 01/23/2017 04:28 AM, Yuri wrote:
>
>> 1. How does it work?
> My response below and the following commit message might answer some of
> your questions:
>
>     http://bazaar.launchpad.net/~squid/squid/5/revision/14769
>
>> I.e., where downloaded certs stored, how it
>> handles, does it saves anywhere to disk?
> Missing certificates are fetched using HTTP[S]. Certificate responses
> should be treated as any other HTTP[S] responses with regard to caching.
> For example, if you have disk caching enabled and your caching rules
> (including defaults) allow certificate response caching, then the
> response should be cached. Similarly, the cached certificate will
> eventually be evicted from the cache following regular cache maintenance
> rules. When that happens, Squid will try to fetch the certificate again
> (if it becomes needed again).
I.e., fetchesd intermediate certificate stores only in memory cache for

sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s
/var/lib/ssl_db -M 4MB

daemon, right? And never stores anywhere on disk?
>
>
>> 2. How this feature is related to sslproxy_foreign_intermediate_certs,
>> how it can interfere with it?
> AFAICT by looking at the code, Squid only downloads certificates that
> Squid is missing when trying to build a complete certificate chain for a
> given server connection. Any sslproxy_foreign_intermediate_certs are
> used as needed during the chain building process (i.e., they are _not_
> "missing").
Ok, so, this file uses for complete chains, and it contains statically
added (manually) certs only, right?

I.e., downloader should not save fetched intermediate CA's here, which
will be logically, isn't it?

>
>
>> Release notes contains nothing about this feature. Wiki contains only
>> one mention in passing that this functionality exists in principle.
> I agree that this feature lacks documentation. This is, in part, because
> the feature has no configuration options that normally force developers
> to document at least some of the code logic. We should add a few words
> about it to sslproxy_foreign_intermediate_certs documentation.
>
>
> FWIW, we are also adding an ACL to identify internal transactions that
> fetch missing certificates.
>
>
> HTH,
>
> Alex.
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Marcus Kool
In reply to this post by Alex Rousskov


On 23/01/17 15:31, Alex Rousskov wrote:
> On 01/23/2017 04:28 AM, Yuri wrote:
>
>> 1. How does it work?
>
> My response below and the following commit message might answer some of
> your questions:
>
>     http://bazaar.launchpad.net/~squid/squid/5/revision/14769

This seems that the feature only goes to Squid 5.  Will it be ported to Squid 4 ?

>> I.e., where downloaded certs stored, how it
>> handles, does it saves anywhere to disk?
>
> Missing certificates are fetched using HTTP[S]. Certificate responses
> should be treated as any other HTTP[S] responses with regard to caching.
> For example, if you have disk caching enabled and your caching rules
> (including defaults) allow certificate response caching, then the
> response should be cached. Similarly, the cached certificate will
> eventually be evicted from the cache following regular cache maintenance
> rules. When that happens, Squid will try to fetch the certificate again
> (if it becomes needed again).
>
>
>> 2. How this feature is related to sslproxy_foreign_intermediate_certs,
>> how it can interfere with it?
>
> AFAICT by looking at the code, Squid only downloads certificates that
> Squid is missing when trying to build a complete certificate chain for a
> given server connection. Any sslproxy_foreign_intermediate_certs are
> used as needed during the chain building process (i.e., they are _not_
> "missing").

I created bug report http://bugs.squid-cache.org/show_bug.cgi?id=4659
a week ago but there has not been any activity.
Is there someone who has sslproxy_foreign_intermediate_certs
working in Squid 4.0.17 ?

Thanks,
Marcus

[snip]

> HTH,
>
> Alex.
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Alex Rousskov
In reply to this post by Yuri Voinov
On 01/23/2017 10:41 AM, Yuri Voinov wrote:
> 23.01.2017 23:31, Alex Rousskov пишет:
>> On 01/23/2017 04:28 AM, Yuri wrote:
>>> I.e., where downloaded certs stored, how it
>>> handles, does it saves anywhere to disk?

>> Missing certificates are fetched using HTTP[S]. Certificate responses
>> should be treated as any other HTTP[S] responses with regard to caching.
>> For example, if you have disk caching enabled and your caching rules
>> (including defaults) allow certificate response caching, then the
>> response should be cached. Similarly, the cached certificate will
>> eventually be evicted from the cache following regular cache maintenance
>> rules. When that happens, Squid will try to fetch the certificate again
>> (if it becomes needed again).

> I.e., fetchesd intermediate certificate stores only in memory cache for
>
> sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s
> /var/lib/ssl_db -M 4MB
>
> daemon, right? And never stores anywhere on disk?

No, this is incorrect -- sslcrtd_program settings are independent from
fetching missing certificates. The ssl_crtd helper is about fake
certificate generation. The helper does not use the Squid cache to cache
its results. The "missing certificates" features are about the virgin
server certificates that are necessary to complete/validate the server
chain but absent from the server's ServerHello response.

The only relationship between the ssl_crtd helper and fetching of the
missing certificates (that I can think of) is that the helper will mimic
the fetched certificates (in some cases). However, I am not even sure
whether the helper gets the virgin incomplete certificate chain or the
completed-by-Squid certificate chain in such cases. I only suspect that
it is the latter. @Christos, please correct me if my suspicion is wrong.


>>> 2. How this feature is related to sslproxy_foreign_intermediate_certs,
>>> how it can interfere with it?
>> AFAICT by looking at the code, Squid only downloads certificates that
>> Squid is missing when trying to build a complete certificate chain for a
>> given server connection. Any sslproxy_foreign_intermediate_certs are
>> used as needed during the chain building process (i.e., they are _not_
>> "missing").

> Ok, so, this file uses for complete chains, and it contains statically
> added (manually) certs only, right?

Yes, the sslproxy_foreign_intermediate_certs file is maintained by the
Squid administrator. Squid does not update it.


> I.e., downloader should not save fetched intermediate CA's here,

Correct.


> which will be logically, isn't it?

I believe it is better to use the regular Squid cache for storing the
fetched missing certificates. I would not call abusing the
sslproxy_foreign_intermediate_certs file for this purpose completely
illogical, but such abuse would create more problems than it would solve
IMO. We have also considered using a dedicated storage for the fetched
missing certificates, but have decided (for many reasons) that it would
be worse than reusing the existing caching infrastructure.

FWIW, IMO, storing the generated fake certificates in the regular Squid
cache would also be better than using an OpenSSL-administered database.


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov


24.01.2017 0:06, Alex Rousskov пишет:

> On 01/23/2017 10:41 AM, Yuri Voinov wrote:
>> 23.01.2017 23:31, Alex Rousskov пишет:
>>> On 01/23/2017 04:28 AM, Yuri wrote:
>>>> I.e., where downloaded certs stored, how it
>>>> handles, does it saves anywhere to disk?
>>> Missing certificates are fetched using HTTP[S]. Certificate responses
>>> should be treated as any other HTTP[S] responses with regard to caching.
>>> For example, if you have disk caching enabled and your caching rules
>>> (including defaults) allow certificate response caching, then the
>>> response should be cached. Similarly, the cached certificate will
>>> eventually be evicted from the cache following regular cache maintenance
>>> rules. When that happens, Squid will try to fetch the certificate again
>>> (if it becomes needed again).
>> I.e., fetchesd intermediate certificate stores only in memory cache for
>>
>> sslcrtd_program /usr/local/squid/libexec/security_file_certgen -s
>> /var/lib/ssl_db -M 4MB
>>
>> daemon, right? And never stores anywhere on disk?
> No, this is incorrect -- sslcrtd_program settings are independent from
> fetching missing certificates. The ssl_crtd helper is about fake
> certificate generation. The helper does not use the Squid cache to cache
> its results. The "missing certificates" features are about the virgin
> server certificates that are necessary to complete/validate the server
> chain but absent from the server's ServerHello response.
>
> The only relationship between the ssl_crtd helper and fetching of the
> missing certificates (that I can think of) is that the helper will mimic
> the fetched certificates (in some cases). However, I am not even sure
> whether the helper gets the virgin incomplete certificate chain or the
> completed-by-Squid certificate chain in such cases. I only suspect that
> it is the latter. @Christos, please correct me if my suspicion is wrong.
>
>
>>>> 2. How this feature is related to sslproxy_foreign_intermediate_certs,
>>>> how it can interfere with it?
>>> AFAICT by looking at the code, Squid only downloads certificates that
>>> Squid is missing when trying to build a complete certificate chain for a
>>> given server connection. Any sslproxy_foreign_intermediate_certs are
>>> used as needed during the chain building process (i.e., they are _not_
>>> "missing").
>> Ok, so, this file uses for complete chains, and it contains statically
>> added (manually) certs only, right?
> Yes, the sslproxy_foreign_intermediate_certs file is maintained by the
> Squid administrator. Squid does not update it.
>
>
>> I.e., downloader should not save fetched intermediate CA's here,
> Correct.
>
>
>> which will be logically, isn't it?
> I believe it is better to use the regular Squid cache for storing the
> fetched missing certificates. I would not call abusing the
> sslproxy_foreign_intermediate_certs file for this purpose completely
> illogical, but such abuse would create more problems than it would solve
> IMO. We have also considered using a dedicated storage for the fetched
> missing certificates, but have decided (for many reasons) that it would
> be worse than reusing the existing caching infrastructure.
>
> FWIW, IMO, storing the generated fake certificates in the regular Squid
> cache would also be better than using an OpenSSL-administered database.
Exactly.
>
>
> HTH,
>
> Alex.
>


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov
In reply to this post by Marcus Kool


24.01.2017 0:06, Marcus Kool пишет:

>
>
> On 23/01/17 15:31, Alex Rousskov wrote:
>> On 01/23/2017 04:28 AM, Yuri wrote:
>>
>>> 1. How does it work?
>>
>> My response below and the following commit message might answer some of
>> your questions:
>>
>>     http://bazaar.launchpad.net/~squid/squid/5/revision/14769
>
> This seems that the feature only goes to Squid 5.  Will it be ported
> to Squid 4 ?
>
>>> I.e., where downloaded certs stored, how it
>>> handles, does it saves anywhere to disk?
>>
>> Missing certificates are fetched using HTTP[S]. Certificate responses
>> should be treated as any other HTTP[S] responses with regard to caching.
>> For example, if you have disk caching enabled and your caching rules
>> (including defaults) allow certificate response caching, then the
>> response should be cached. Similarly, the cached certificate will
>> eventually be evicted from the cache following regular cache maintenance
>> rules. When that happens, Squid will try to fetch the certificate again
>> (if it becomes needed again).
>>
>>
>>> 2. How this feature is related to sslproxy_foreign_intermediate_certs,
>>> how it can interfere with it?
>>
>> AFAICT by looking at the code, Squid only downloads certificates that
>> Squid is missing when trying to build a complete certificate chain for a
>> given server connection. Any sslproxy_foreign_intermediate_certs are
>> used as needed during the chain building process (i.e., they are _not_
>> "missing").
>
> I created bug report http://bugs.squid-cache.org/show_bug.cgi?id=4659
> a week ago but there has not been any activity.
> Is there someone who has sslproxy_foreign_intermediate_certs
> working in Squid 4.0.17 ?
Seems works as by as in 3.5.x. As I can see.

>
> Thanks,
> Marcus
>
> [snip]
>
>> HTH,
>>
>> Alex.
>>
>> _______________________________________________
>> squid-users mailing list
>> [hidden email]
>> http://lists.squid-cache.org/listinfo/squid-users
>>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Marcus Kool


On 23/01/17 17:23, Yuri Voinov wrote:
[snip]

>> I created bug report http://bugs.squid-cache.org/show_bug.cgi?id=4659
>> a week ago but there has not been any activity.
>> Is there someone who has sslproxy_foreign_intermediate_certs
>> working in Squid 4.0.17 ?
> Seems works as by as in 3.5.x. As I can see.

3.5.x works fine but 4.0.17 fails on my servers.

>>
>> Thanks,
>> Marcus
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov


24.01.2017 2:25, Marcus Kool пишет:

>
>
> On 23/01/17 17:23, Yuri Voinov wrote:
> [snip]
>
>>> I created bug report http://bugs.squid-cache.org/show_bug.cgi?id=4659
>>> a week ago but there has not been any activity.
>>> Is there someone who has sslproxy_foreign_intermediate_certs
>>> working in Squid 4.0.17 ?
>> Seems works as by as in 3.5.x. As I can see.
>
> 3.5.x works fine but 4.0.17 fails on my servers.
My test 4.0.17 works. Seems same like 3.5.
>
>>>
>>> Thanks,
>>> Marcus
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Amos Jeffries
Administrator
In reply to this post by Yuri Voinov
On 24/01/2017 8:22 a.m., Yuri Voinov wrote:

>
>
> 24.01.2017 0:06, Alex Rousskov пишет:
>> On 01/23/2017 10:41 AM, Yuri Voinov wrote:
>>> 23.01.2017 23:31, Alex Rousskov пишет:
>>>> On 01/23/2017 04:28 AM, Yuri wrote:
>>
>>>>> 2. How this feature is related to sslproxy_foreign_intermediate_certs,
>>>>> how it can interfere with it?
>>>> AFAICT by looking at the code, Squid only downloads certificates that
>>>> Squid is missing when trying to build a complete certificate chain for a
>>>> given server connection. Any sslproxy_foreign_intermediate_certs are
>>>> used as needed during the chain building process (i.e., they are _not_
>>>> "missing").
>>> Ok, so, this file uses for complete chains, and it contains statically
>>> added (manually) certs only, right?
>> Yes, the sslproxy_foreign_intermediate_certs file is maintained by the
>> Squid administrator. Squid does not update it.
>>
>>
>>> I.e., downloader should not save fetched intermediate CA's here,
>> Correct.
>>
>>
>>> which will be logically, isn't it?
>> I believe it is better to use the regular Squid cache for storing the
>> fetched missing certificates. I would not call abusing the
>> sslproxy_foreign_intermediate_certs file for this purpose completely
>> illogical, but such abuse would create more problems than it would solve
>> IMO. We have also considered using a dedicated storage for the fetched
>> missing certificates, but have decided (for many reasons) that it would
>> be worse than reusing the existing caching infrastructure.
>>
>> FWIW, IMO, storing the generated fake certificates in the regular Squid
>> cache would also be better than using an OpenSSL-administered database.
> Exactly.

There is one drawback to that suggestion though.

The certs which are downloaded are publicly available information and
intended to be such. Anyone can download them from source just like
browsers and Squid-4 do. So there is no harm in having the data stored
in a semi-insecure cache.

The cert generated by Squid are pollution as far as TLS is concerned.
Intended for use only by that proxy installation with the specific set
of details involved with the origin certificate on that connection.
Re-usability is purely a bonus. People could get into connectivity
trouble if they were stored long-term like other cache items.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Amos Jeffries
Administrator
In reply to this post by Marcus Kool
On 24/01/2017 7:06 a.m., Marcus Kool wrote:

>
>
> On 23/01/17 15:31, Alex Rousskov wrote:
>> On 01/23/2017 04:28 AM, Yuri wrote:
>>
>>> 1. How does it work?
>>
>> My response below and the following commit message might answer some of
>> your questions:
>>
>>     http://bazaar.launchpad.net/~squid/squid/5/revision/14769
>
> This seems that the feature only goes to Squid 5.  Will it be ported to
> Squid 4 ?

rev.14769 is from before Squid-5 existed (rev.14932). The commits
labeled 'trunk' at that time were Squid-4.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Alex Rousskov
In reply to this post by Amos Jeffries
On 01/23/2017 03:59 PM, Amos Jeffries wrote:
> On 24/01/2017 8:22 a.m., Yuri Voinov wrote:
>> 24.01.2017 0:06, Alex Rousskov пишет:
>>> FWIW, IMO, storing the generated fake certificates in the regular Squid
>>> cache would also be better than using an OpenSSL-administered database.

>> Exactly.

> There is one drawback to that suggestion though.

> The cert generated by Squid are pollution as far as TLS is concerned.

TLS has nothing to do with this decision though. Whether it is a good
idea to store something in a cache is determined primarily by two
factors: Reusability (i.e., the probability of a hit) and hit cost
(relative to a miss cost).


> Intended for use only by that proxy installation with the specific set
> of details involved with the origin certificate on that connection.
> Re-usability is purely a bonus. People could get into connectivity
> trouble if they were stored long-term like other cache items.

Sorry, I do not understand your argument. It seems to be revolving
around re-usability and "connectivity trouble". Both problems may be
about the same underlying concern, but I am addressing them separately:

* Both fake certificates and many other cached items are reusable, often
short- and sometimes long-term so there does not seem to be an important
difference as far as the probability of a hit is concerned. In fact,
fake certificates may be more reusable long-term than an average cached
HTTP response because the certificates they mimic and the mimicking
parameters are often stable for many days or even weeks.

* As for the "connectivity trouble", I assume that you are talking about
the cache user getting a stale (i.e., no longer applicable) fake
certificate from the cache without realizing it. I believe HTTP has
solutions for that problem already; any implementation using HTTP cache
for fake certificates would need to use the right HTTP knobs to ensure
freshness/applicability of the previously cached fake certificate to its
current user. Moreover, the existing fake certificate cache has to solve
exactly the same problem anyway, and does not have more appropriate
tools than an HTTP cache can offer.


AFAICT, the only real doubt regarding fake certificate caching is
whether the cost of generating the correct cache request (and/or
validating the hit response) is significantly lower than the cost of
generating a new fake certificate from scratch (i.e., the miss-vs-hit
cost factor). That problem exist for any cache, generic HTTP or
certificate-specific one. AFAIK, it needs studying/experiments.


Cheers,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov
In reply to this post by Amos Jeffries
Hm. Another question.

It seems 4.0.17 tries to download certs:

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

but gives deny somewhere.

However, same URL with wget via same proxy works:

root @ khorne /patch # wget -S http://repository.certum.pl/ca.cer
--2017-01-24 23:46:37--  http://repository.certum.pl/ca.cer
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response...
  HTTP/1.1 200 OK
  Content-Type: text/plain; charset=UTF-8
  Content-Length: 784
  Last-Modified: Fri, 07 Mar 2014 10:05:14 GMT
  ETag: "34231-310-63d6aa80"
  X-Cached: MISS
  Server: NetDNA-cache/2.2
  X-Cache: HIT
  Accept-Ranges: bytes
  X-Origin-Date: Mon, 23 Jan 2017 06:12:38 GMT
  Date: Tue, 24 Jan 2017 17:46:37 GMT
  X-Cache-Age: 128039
  X-Cache: HIT from khorne
  X-Cache-Lookup: HIT from khorne:3128
  Connection: keep-alive
Length: 784 [text/plain]
Saving to: 'ca.cer.2'

ca.cer.2            100%[==================>]     784  --.-KB/s    in
0s    

2017-01-24 23:46:37 (95.7 MB/s) - 'ca.cer.2' saved [784/784]

Why? Downloader requires special ACL? Or something else undocumented?


24.01.2017 5:08, Amos Jeffries пишет:

> On 24/01/2017 7:06 a.m., Marcus Kool wrote:
>>
>> On 23/01/17 15:31, Alex Rousskov wrote:
>>> On 01/23/2017 04:28 AM, Yuri wrote:
>>>
>>>> 1. How does it work?
>>> My response below and the following commit message might answer some of
>>> your questions:
>>>
>>>     http://bazaar.launchpad.net/~squid/squid/5/revision/14769
>> This seems that the feature only goes to Squid 5.  Will it be ported to
>> Squid 4 ?
> rev.14769 is from before Squid-5 existed (rev.14932). The commits
> labeled 'trunk' at that time were Squid-4.
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

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.


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov
Mmmmmm, hardly.

It is downloads directly via proxy from localhost:

root @ khorne /patch # http_proxy=localhost:3128 curl
http://repository.certum.pl/ca.cer
0
0>1     *H
   0    UPL1U
270611104639Z0>1o.10U   Certum CA0
                0       UPL1U
0       *H. z o.o.10U   Certum CA0"0
AK°jk̘󽢟gŭ&_O𣕨Ώ¸솶n줝ªn9¾䑯؇ r캦[¯ɓ?㆖͡Vn𨦩S    ^Ucը𐳱.0h³¼جnZN4ڶP·mB      𗕃
ºO)¥B^¶
¸ϯ唺Ю°Dl´9>¢n­¸!wӔw䟁·cϗ7¾v֫$L齪go-Սþe1pÂ
{mXIþc2
       kỀ¬«;°鑠   QĴძ󾚶`'l2w¼²rЍʿ¹ƤB՗񃧝倐̃T(>򀔸M
:;#c?ч'y䋑ၭ];±Գ¤Բ¼nd𙖐¨ƌt.q;爴io𐞃|R®𒧙gۼpݛ±i큎@Hj5ȩf!,瞪J@򫈤ꄖ,s

root @ khorne /patch #

root @ khorne /patch # wget -S http://repository.certum.pl/ca.cer
--2017-01-24 23:59:54--  http://repository.certum.pl/ca.cer
Connecting to 127.0.0.1:3128... connected.
Proxy request sent, awaiting response...
  HTTP/1.1 200 OK
  Content-Type: text/plain; charset=UTF-8
  Content-Length: 784
  Last-Modified: Fri, 07 Mar 2014 10:05:14 GMT
  ETag: "34231-310-63d6aa80"
  X-Cached: MISS
  Server: NetDNA-cache/2.2
  X-Cache: HIT
  Accept-Ranges: bytes
  X-Origin-Date: Mon, 23 Jan 2017 06:12:38 GMT
  Date: Tue, 24 Jan 2017 17:59:54 GMT
  X-Cache-Age: 128836
  X-Cache: HIT from khorne
  X-Cache-Lookup: HIT from khorne:3128
  Connection: keep-alive
Length: 784 [text/plain]
Saving to: 'ca.cer'

ca.cer              100%[==================>]     784  --.-KB/s    in
0s    

2017-01-24 23:59:54 (86.2 MB/s) - 'ca.cer' saved [784/784]

As I understand, downloader also access via localhost, right? So, it
should work.

Either from localnet, or from localhost download occurs.


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.
>
>
> HTH,
>
> Alex.
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov
May be, this feature is mutually exclusive with
sslproxy_foreign_intermediate_certs option?


25.01.2017 0:19, Yuri Voinov пишет:

> Mmmmmm, hardly.
>
> It is downloads directly via proxy from localhost:
>
> root @ khorne /patch # http_proxy=localhost:3128 curl
> http://repository.certum.pl/ca.cer
> 0
> 0>1     *H
>    0    UPL1U
> 270611104639Z0>1o.10U   Certum CA0
>                 0       UPL1U
> 0       *H. z o.o.10U   Certum CA0"0
> AK°jk̘󽢟gŭ&_O𣕨Ώ¸솶n줝ªn9¾䑯؇ r캦[¯ɓ?㆖͡Vn𨦩S    ^Ucը𐳱.0h³¼جnZN4ڶP·mB      𗕃
> ºO)¥B^¶
> ¸ϯ唺Ю°Dl´9>¢n­¸!wӔw䟁·cϗ7¾v֫$L齪go-Սþe1pÂ
> {mXIþc2
>        kỀ¬«;°鑠   QĴძ󾚶`'l2w¼²rЍʿ¹ƤB՗񃧝倐̃T(>򀔸M
> :;#c?ч'y䋑ၭ];±Գ¤Բ¼nd𙖐¨ƌt.q;爴io𐞃|R®𒧙gۼpݛ±i큎@Hj5ȩf!,瞪J@򫈤ꄖ,s
>
> root @ khorne /patch #
>
> root @ khorne /patch # wget -S http://repository.certum.pl/ca.cer
> --2017-01-24 23:59:54--  http://repository.certum.pl/ca.cer
> Connecting to 127.0.0.1:3128... connected.
> Proxy request sent, awaiting response...
>   HTTP/1.1 200 OK
>   Content-Type: text/plain; charset=UTF-8
>   Content-Length: 784
>   Last-Modified: Fri, 07 Mar 2014 10:05:14 GMT
>   ETag: "34231-310-63d6aa80"
>   X-Cached: MISS
>   Server: NetDNA-cache/2.2
>   X-Cache: HIT
>   Accept-Ranges: bytes
>   X-Origin-Date: Mon, 23 Jan 2017 06:12:38 GMT
>   Date: Tue, 24 Jan 2017 17:59:54 GMT
>   X-Cache-Age: 128836
>   X-Cache: HIT from khorne
>   X-Cache-Lookup: HIT from khorne:3128
>   Connection: keep-alive
> Length: 784 [text/plain]
> Saving to: 'ca.cer'
>
> ca.cer              100%[==================>]     784  --.-KB/s    in
> 0s    
>
> 2017-01-24 23:59:54 (86.2 MB/s) - 'ca.cer' saved [784/784]
>
> As I understand, downloader also access via localhost, right? So, it
> should work.
>
> Either from localnet, or from localhost download occurs.
>
>
> 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.
>>
>>
>> HTH,
>>
>> Alex.
>>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Alex Rousskov
In reply to this post by Yuri Voinov
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.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov
This is working production server. I've checked configuration twice. See
no problem.

Here:


# -------------------------------------
# Access parameters
# -------------------------------------
# Deny requests to unsafe ports
http_access deny !Safe_ports

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

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

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager
http_access deny to_localhost
# Allow purge from localhost
http_access allow PURGE localhost
http_access deny PURGE

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

# No cache directives
cache deny dont_cache_url
cache allow all

# 302 loop
acl text_mime rep_mime_type text/html text/plain
acl http302 http_status 302
store_miss deny text_mime http302
send_hit deny text_mime http302

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

# SSL bump rules
acl DiscoverSNIHost at_step SslBump1
acl NoSSLIntercept ssl::server_name_regex
"/usr/local/squid/etc/acl.url.nobump"
ssl_bump peek DiscoverSNIHost
ssl_bump splice DiscoverSNIHost icq
ssl_bump splice DiscoverSNIHost icqip icqport
ssl_bump splice NoSSLIntercept
ssl_bump bump all

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

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

is ok.

I'm only on doubt about this:

http_access deny to_localhost

but it is recommended to use long time, as documented:

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

and has no visible effect to comment out this line.

I have no idea, what can block access.

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.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Squid 4.x: Intermediate certificates downloader

Yuri Voinov


25.01.2017 1:10, 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.
Yes, irrelevant.
>
>
>> # Deny CONNECT to other than SSL ports
>> http_access deny CONNECT !SSL_ports
> Does not match. This is a GET request.
Exactly.

>
>
>> # 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.
Yes, destination is squid itself. From squid to squid.

>
>
>> # 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.
Exactly.
>
>
>> # 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!

>
>
>> 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.
Yes. I've tought about debugging.

>
> 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.
Here is in doubt. I tought I've good knowlegde about squid's acl. But I
don't know (on first look) special ACL rule to permit internal access
from squid to squid.

I'm reading documented config - there is no special ACL type to
permit/deny internal access.

Hmmmmmmmmmm. It looks squid blocks own internal access to itself, but
permits the same request from outside.

Can this be bug? Or I lost something?

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

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

0x613DEC46.asc (2K) Download Attachment
signature.asc (484 bytes) Download Attachment
12
Loading...