<div dir="ltr">Hi Amos,<div><br></div><div>I tried your suggestion tried to tuned with some other options, no matter what I've done, seems HTTPS traffic will not look at sibling cache? it only look into it's own cache if there are only siblings in the group?</div><div><br></div><div><br></div><div>Thanks,</div><div>Lei</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 27, 2017 at 8:36 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 28/07/17 10:32, Lei Wen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Amos,<br>
<br>
    /Squid does not support relaying decrypted https:// requests over an<br>
    insecure connection. So HTTP cache_peer connections will be refused./<span class=""><br>
<br>
Do you mean HTTPS cache_peer connections will be refused?<br>
</span></blockquote>
<br>
No, I mean un-encrypted cache_peer connections will be refused.<br>
<br>
Encrypted peers might be used, BUT the peer cert is used for the fake-cert generation. Usually the end user then encounters 'invalid cert' problems. One also has to be very careful not to introduce other MITM or downgrade vulnerabilities on the connections to those peers.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    /Also, when TLS cache_peer is used Squid is unable to tell the<span class=""><br>
    difference between the peer TLS server details an origin. So any<br>
    server-cert forging uses the cache_peer's server cert instead of the<br></span>
    origin./<span class=""><br>
<br>
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?<br>
</span></blockquote>
<br>
No, any sibling may pass the request on to any other. If the first proxy to handle a request thinks that a peer has the response and that peer in fact does not, it may be passed on to a third sibling, etc.<br>
<br>
<br>
It does not matter if the certs on the proxies are identical or not. The SSL-Bump is ideally not sending that particular cert to the clients. It is generating a fake cert specific for each HTTPS domain being visited - based on that domains real official cert.<br>
To do that Squid expected to receive that origin servers cert on its next-hop connection.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
    /In Squid-3.5 (and v4) explicit/forward proxy it is best not to use<span class=""><br>
    cache_peer for decrypted content. The most working way for now is to<br></span>
    let it go 'DIRECT' and repeat the intercept at the peer./<span class=""><br>
<br>
Which directive do you mean by 'DIRECT' as a replacement of cache_peer?<br>
<br>
</span></blockquote>
<br>
"DIRECT" in caching hierarchy, means the proxy handling the request uses DNS records to identify the origin server and goes directly to that (not through a cache_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>
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.<br>
</blockquote>
<br></span>
Okay, understood.<br>
<br>
You might be able to get a sort-of workable situation with the following parameters. I'd still expect a lot of annoying problems though.<br>
<br>
<br>
 cache_peer <a href="http://sibling.example.com" rel="noreferrer" target="_blank">sibling.example.com</a> sibling 3128 3130 \<br>
   ssl sslcafile=/path/to/ca.pem \<br>
   sslflags=NO_DEFAULT_CA ssloptions=NO_SSLv3<br>
<br>
<br>
The /path/to/ca.pem should contain the public cert of the CA used to sign the peers cert. Do this whether it is a self-signed CA or a public Trusted CA.<br>
<br>
[avoid the DONT_VERIFY_* settings, they are deadly].<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Amos<br>
</font></span></blockquote></div><br></div>