[squid-users] Secrecy and TCP Reset and Allow Direct
squid3 at treenet.co.nz
Sun Dec 4 00:03:29 UTC 2016
On 4/12/2016 12:38 p.m., creditu wrote:
> On Sat, Dec 3, 2016, at 04:13 PM, Amos Jeffries wrote:
>> On 4/12/2016 11:08 a.m., creditu wrote:
>>> I am trying to finalize an accelerator configuration in 3.1. The
>>> accelerator has cache disabled (we use an external service) with cache
>>> deny all. We have several public IPs that send requests to back end
>>> Apache servers using http. The accelerator will provide both http and
>>> https for a while. A few questions:
>>> Trying to get a A rating in Qualys site and the best I can get is A- due
>>> to forward secrecy not supported for a few browsers. I think this is
>>> due to Squid not being able to support ECDHE (which some of those
>>> browsers need). Just wanted to confirm that we're not missing
>>> something. Is there any alternate configuration that we may be able to
>> ECDHE is enabled when the https_port tls-dh= option is given a curve
>> name. This is supported in 3.5.13+.
> Thanks and good to know. We'll work on the upgrade once we can get the
> 3.1 online.
>>> I have an ACL that I want to send a TCP reset if the url being requested
>>> matches a regx. It seems to work, but in testing the first time a
>>> browser request the url, the upper left corner of the browser has the
>>> word "reset" in it. Subsequent requests seem to work as expected and
>>> the client/browser gets the reset. In the cache log I see:
>>> errorpage.cc(293) errorTryLoadText:
>>> '/usr/share/squid/errors/en-us/TCP_RESET': (2) No such file or
>>> WARNING: Error Pages Missing Language: en-us
>>> errorpage.cc(293) errorTryLoadText:
>>> '/usr/share/squid/errors/en/TCP_RESET': (2) No such file or directory"
>>> "WARNING: Error Pages Missing Language: en
>>> I touched an empty file in the directories and the errors went away.
>>> Now after a squid restart I get "max-age=86400" in the upper left corner
>>> once then it goes away and works as expected (client gets reset). Just
>>> curious if this is expected? Here is the ACL:
>>> acl www_url url_regex -i [^:]+://www.example.com.*
>>> deny_info TCP_RESET www_url
>> You can omit the trailing ".*" , but yes that is correct.
>> The browser showing some text is odd. You can use "debug_options 11,2"
>> to get a cache.log trace of the HTTP message headers and see what is
>> going on there.
> Okay, will give it a try.
Sorry. I overlooked your version number when writing that. The 11,2 wont
work in 3.1. You need a tcpdump trace to see what is going on for that
>>> Trying to understand if we should use the always direct directive with
>>> this configuration. As stated, we just want to send public requests to
>>> the backend servers. The current ACL for this is:
>>> acl apache dst 10.10.10.0/24
>>> always_direct allow apache
>>> always_direct deny all
>> This directives only purpose is to prevent cache_peer links being used
>> for the traffic which has an "allow" action.
> Still a little confused if I need it. Based on what you said I think I
> don't, but it doesn't seem to hurt anything that I can tell. My
If you dont know of a need for it, you dont need it.
Given the below config then it will prevent any future cache_peer
settings working when you extend them to things beyond basic
It is already stopping the round-robin being used properly (since no
traffic over those PARENT links). If you see any balancing at all with
that always_direct set then its being done solely via the DNS response
rotation in the DIRECT traffic.
> cache_peer statements send to backend apache servers and we have
> disabled all caching, for example:
> acl www_site dstdomain www.example.com
> cache_peer 10.10.10.1 parent 80 0 no-query no-digest originserver
> cache_peer_access 10.10.10.1 allow www_site
> cache_peer_access 10.10.10.1 deny all
> cache_peer 10.10.10.2 parent 80 0 no-query no-digest originserver
> cache_peer_access 10.10..10.2 allow www_site
> cache_peer_access 10.10.10.2 deny all
> Thanks Again. Appreciate the help.
More information about the squid-users