<div dir="ltr">Hi Amos,<div><span class="gmail-im" style="font-size:12.8px"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"><i>Squid does not support relaying decrypted https:// requests over an insecure connection. So HTTP cache_peer connections will be refused.</i><span class="gmail-"></span></span></blockquote><div style="font-size:small"><span style="font-size:12.8px">Do you mean HTTPS cache_peer connections will be refused?</span><br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"><i>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></span><br style="font-size:12.8px"></blockquote><div><span style="font-size:small">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?</span><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px"><i>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></span></blockquote></span>Which directive do you mean by 'DIRECT' as a replacement of cache_peer?<br style="font-size:12.8px"></div><div><br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div>Thanks,</div><div>Lei</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 26, 2017 at 3:30 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 27/07/17 09:54, Lei Wen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Amos,<br>
<br>
Thanks a lot.<br>
It is my splice thing is blocking proxy in the middle,<br>
</blockquote>
<br></span>
Sort of, yes.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
after using stare instead of peek, seems work though, terminal in this case is not blocking proxy in the middle?<br>
<br>
</blockquote>
<br></span>
Not sure what you are asking there. Squid *is* the proxy in the middle, so terminate does a TCP close().<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I made some change on my squid.conf, it work for http/https caching and http/https whitelist.<br>
It is working for http sibling cache as well, but has some issue with https/ssl sibling cache.<br>
in cache_peer, which port number should I use as forward-proxy port? 3130/3128/3129?<br>
</blockquote>
<br></span>
Squid does not support relaying decrypted https:// requests over an insecure connection. So HTTP cache_peer connections will be refused.<br>
<br>
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.<br>
<br>
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.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am trying to set up a sibling cache pool, there is no parent or gateway sort of thing in this hierarchy.<br>
Each instance can have their own whitelist, but they share the same cache pool.<br>
On each instance host, squid is actually doing it's whitelist and caching job for a container group on the same host.<br>
<br>
</blockquote>
<br></span>
Are you trying to describe something like a CARP hierarchy?<br>
<<a href="http://wiki.squid-cache.org/ConfigExamples/SmpCarpCluster" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/C<wbr>onfigExamples/SmpCarpCluster</a>><br>
<br>
They suffer from the above problem. There is no good solution for that in current Squid versions which do SSL-Bump.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
acl step1 at_step SslBump1<br>
acl step2 at_step SslBump2<br>
acl step3 at_step SslBump3<br>
ssl_bump stare step1 all<br>
ssl_bump stare step2 allowed_https_sites<br>
#ssl_bump bump step3<br>
ssl_bump terminate step2 all<br>
<br>
</blockquote>
<br>
<br></span>
Up to you, but I would do this:<br>
<br>
ssl_bump peek step1<br>
<br>
ssl_bump stare step2 allowed_https_sites<br>
ssl_bump terminate step2<br>
<br>
# decrypt with server-cert forging<br>
ssl_bump bump step3<br>
<br>
<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Amos<br>
</font></span></blockquote></div><br></div>