<div dir="ltr">Hi Amos,<div><br></div><div>Thanks a lot.</div><div>It is my splice thing is blocking proxy in the middle, after using stare instead of peek, seems work though, terminal in this case is not blocking proxy in the middle?</div><div><br></div><div>I made some change on my squid.conf, it work for http/https caching and http/https whitelist.</div><div>It is working for http sibling cache as well, but has some issue with https/ssl sibling cache.</div><div>in cache_peer, which port number should I use as <span style="font-size:12.8px">forward-proxy port? 3130/3128/3129?</span></div><div><br></div><div>I am trying to set up a sibling cache pool, there is no parent or gateway sort of thing in this hierarchy.</div><div>Each instance can have their own whitelist, but they share the same cache pool.</div><div>On each instance host, squid is actually doing it's whitelist and caching job for a container group on the same host.</div><div><br></div><div><br></div><div><div>http_port 3130</div><div><br></div><div>http_port 3128 intercept</div><div>acl allowed_http_sites dstdomain "/etc/squid3/whitelist.txt"</div><div>http_access allow allowed_http_sites</div><div><br></div><div>https_port 3129 cert=/etc/squid3/squid.crt key=/etc/squid3/squid.key ssl-bump intercept generate-host-certificates=on dynamic_cert_mem_cache_size=4MB</div><div>acl SSL_port port 443</div><div>http_access allow SSL_port</div><div>acl allowed_https_sites ssl::server_name "/etc/squid3/ssl_sites.txt"</div><div><br></div><div>http_access deny all</div></div><div><br></div><div><div>acl step1 at_step SslBump1</div><div>acl step2 at_step SslBump2</div><div>acl step3 at_step SslBump3</div><div>ssl_bump stare step1 all</div><div>ssl_bump stare step2 allowed_https_sites</div><div>#ssl_bump bump step3</div><div>ssl_bump terminate step2 all</div></div><div><br></div><div><div>icp_port 3131</div><div>icp_access allow all</div><div>cache_peer 10.0.8.48 sibling 3130 3131 proxy-only</div></div><div><br></div><div><br></div><div><br></div><div>Thanks,</div><div>Lei</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 25, 2017 at 9:42 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 26/07/17 10:56, Lei Wen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I am setting up a transparent proxy that is doing whitelist work, and at the same time, doing the cache work.<br>
<br>
<br>
The whitelist works fine, HTTP cache verifed work cause I see TCP_MEM_HIT using this squid.conf, but don't see any HTTPS MEM HIT related log, every time seems a new connection.<br>
</blockquote>
<br>
<br></span>
Nod. HIT and REFRESH log entries show cache usage. Squid versions with SSL-Bump support are more likely to show REFRESH.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For HTTPS traffic, I am getting TCP_TUNNEL/200 all the time, the question is, how can I tell that a HTTPS traffic is actually using cache, or in this case, it's not using cache at all for HTTPS. I am using forward-proxy port in cache_peer.<br>
</blockquote>
<br></span>
That TUNNEL shows SSL-Bump splice action happening, or SSL-Bump not even being considered (ie traffic received in your Squids' port 3130 and 3128).<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 understand that there is logformat to make access.log show hostname instead of ip, but this should not effect the MEM HIT log, right?<br>
<br>
Meanwhile, I am also trying to setup the sibling cache cluster, not sure if this related to HTTPS cache, I am also getting TCP_DENIED/403 for squid-internal-dynamic/netdb - HIER_NONE/- text/html. I do see sibling hit for HTTP site.<br>
<br>
</blockquote>
<br></span>
You have configured splice or terminate. No bumping / decryption will ever happen, so the cache is never even considered for use.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And my squid.conf<br>
<br>
# Squid normally listens to port 3128<br>
<br>
http_port 3130<br>
<br>
<br>
http_port 3128 intercept<br>
<br>
acl allowed_http_sites dstdomain "/etc/squid3/whitelist.txt"<br>
<br>
http_access allow allowed_http_sites<br>
<br>
<br>
https_port 3129 cert=/etc/squid3/squid.crt key=/etc/squid3/squid.key ssl-bump intercept generate-host-certificates=on dynamic_cert_mem_cache_size=4M<wbr>B<br>
<br>
acl SSL_port port 443<br>
<br>
http_access allow SSL_port<br>
<br>
</blockquote>
<br></span>
There are now almost no restrictions on port 443. Anyone can get through it so long as they claim to be contacting one of the allowed_https_sites (a the HTTP CONNECT level, not the TLS is unrestricted).<br>
That includes traffic in the ports 3130 and 3128 which are not considered for ssl_bump processing.<span class=""><br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
acl allowed_https_sites ssl::server_name "/etc/squid3/ssl_sites.txt"<br>
<br>
#sslcrtd_program /usr/local/squid/libexec/ssl_c<wbr>rtd -s /var/lib/ssl_db -M 4MB<br>
<br>
sslcrtd_program /lib/squid3/ssl_crtd -s /var/lib/ssl_db -M 4MB<br>
<br>
<br>
<br>
acl step1 at_step SslBump1<br>
<br>
acl step2 at_step SslBump2<br>
<br>
acl step3 at_step SslBump3<br>
<br>
ssl_bump peek step1 all<br>
<br>
ssl_bump peek step2 allowed_https_sites<br>
</blockquote>
<br></span>
dstdomain ACL is not reliable in ssl_bump. It uses the HTTP URI domain from the previous CONNECT instead of the actual TLS details.<br>
Use ssl::server_name ACL type instead.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
ssl_bump splice step3 allowed_https_sites<br>
<br>
ssl_bump terminate step2 all<br>
</blockquote>
<br></span>
So what happens when the server TLS cert reveals it is not actually serving up one of the allowed_https_sites? nothing, the traffic is allowed through.<br>
<br>
<br>
Note the terminate line only gets used at step2 (ie. based on client SNI claims alone). The peek at step2 has precluded / prohibited bump from happening at step3, which only leaves splice as being possible.<br>
<br>
<br>
Amos<br>
______________________________<wbr>_________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.<wbr>org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/l<wbr>istinfo/squid-users</a><br>
</blockquote></div><br></div>