Hi Amos,
Squid does not support relaying decrypted https:// requests over an insecure connection. So HTTP cache_peer connections will be refused.
Do you mean HTTPS cache_peer connections will be refused?
Also, when TLS cache_peer is used Squid is unable to tell the difference between the peer TLS server details an origin. So any server-cert forging uses the cache_peer's server cert instead of the origin.
I am using the same cert on every host, so it doesn't matter if it picks the peer's cert. Besides, I have all sibling relation in this pool, only parent will start the request for peer, right?
In Squid-3.5 (and v4) explicit/forward proxy it is best not to use cache_peer for decrypted content. The most working way for now is to let it go 'DIRECT' and repeat the intercept at the peer.Which directive do you mean by 'DIRECT' as a replacement of cache_peer?
My setup doesn't have many layers like a CARP cluster, it's just a squid host pool, and they are all siblings with each other, no parent/frontend/backend concept, each squid host is also a container host, all containers on different host are doing similar job, so they can share cache between different hosts. This is our initial idea for this project if you know there are better hierarchy and can give me some suggest I am really appreciate.
Thanks,
Lei
On Wed, Jul 26, 2017 at 3:30 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 27/07/17 09:54, Lei Wen wrote:
Hi Amos,
Thanks a lot.
It is my splice thing is blocking proxy in the middle,
Sort of, yes.
after using stare instead of peek, seems work though, terminal in this case is not blocking proxy in the middle?
Not sure what you are asking there. Squid *is* the proxy in the middle, so terminate does a TCP close().
I made some change on my squid.conf, it work for http/https caching and http/https whitelist.
It is working for http sibling cache as well, but has some issue with https/ssl sibling cache.
in cache_peer, which port number should I use as forward-proxy port? 3130/3128/3129?
Squid does not support relaying decrypted https:// requests over an insecure connection. So HTTP cache_peer connections will be refused.
Also, when TLS cache_peer is used Squid is unable to tell the difference between the peer TLS server details an origin. So any server-cert forging uses the cache_peer's server cert instead of the origin.
In Squid-3.5 (and v4) explicit/forward proxy it is best not to use cache_peer for decrypted content. The most working way for now is to let it go 'DIRECT' and repeat the intercept at the peer.
I am trying to set up a sibling cache pool, there is no parent or gateway sort of thing in this hierarchy.
Each instance can have their own whitelist, but they share the same cache pool.
On each instance host, squid is actually doing it's whitelist and caching job for a container group on the same host.
Are you trying to describe something like a CARP hierarchy?
<http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster >
They suffer from the above problem. There is no good solution for that in current Squid versions which do SSL-Bump.
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump stare step1 all
ssl_bump stare step2 allowed_https_sites
#ssl_bump bump step3
ssl_bump terminate step2 all
Up to you, but I would do this:
ssl_bump peek step1
ssl_bump stare step2 allowed_https_sites
ssl_bump terminate step2
# decrypt with server-cert forging
ssl_bump bump step3
That peek at step1 allows Squid can splice if things to badly at the step2 staring. A peek at step1 will not prevent a step3 bump.
And the explicit line with 'bump' ensures that Squid actually does a bump, the default behaviour is a little bit too variable depending on what bugs are present in the SSL-Bump code.
Amos
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
