<div dir="ltr"><div>I have redeployed everything, with most basic configuration, and use the proposed config for ssl_bump.</div><div>The test server that goes through Squid now doesn't get tunneled, and instead checks the cache. I get something like this</div><div>NONE/200<br>TCP_MISS/200</div><div><br></div><div>But I have noticed that the test server also doesn't cache anything, and instead only looks at the cache.</div><div>So if I try to go for a file in S3, it says MISS, and after that, MISS again, and I see no new objects in cache being created.</div><div>If I try the same thing from the proxy itself, I get the MISS, and the object gets cached, as it should.<br></div><div>When I go back to the test server, and try again, it sees the object in cache and returns TCP_MEM_HIT/200 instead.</div><div><br></div><div>Is
 there a specific configuration that I need to add/enable, in order to 
have the server cache the objects, or am I making a mistake elsewhere 
perhaps?</div><div>This is the entire config file:</div><div><br></div><div><br></div><div>visible_hostname squid<br>cache_dir ufs /test/cache/squid 10000 16 256<br></div><div><br></div><div>http_access allow localhost<br>http_access alow all<span class="gmail-im"><br><br>http_port 3128<br>http_port 3129 intercept<br>acl allowed_http_sites dstdomain .<a href="http://amazonaws.com" target="_blank">amazonaws.com</a><br>http_access allow allowed_http_sites<br><br>https_port 3130 cert=/etc/squid/ssl/squid.pem ssl-bump intercept<br>acl SSL_port port 443<br>http_access allow SSL_port<br></span>acl allowed_https_sites ssl::server_name .<a href="http://amazonaws.com" target="_blank">amazonaws.com</a><br><br>ssl_bump stare all<br>ssl_bump bump allowed_https_sites<br>ssl_bump terminate all</div><div><br></div><div><br></div><div><br></div><div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 26, 2021 at 9:14 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/26/21 1:54 PM, Milos Dodic wrote:<br>
<br>
> when the test server goes for a picture I have stored somewhere in<br>
> the cloud, the squid access log shows "TCP_TUNNEL/200". But when I<br>
> try from the proxy itself with squidclient tool, I get<br>
> "TCP_MEM_HIT/200"<br>
<br>
<br>
Given the very limited information you have provided, I am guessing that<br>
<br>
* the primary tests opens a CONNECT tunnel through Squid<br>
* the squidclient test sends a plain text HTTP request to Squid<br>
<br>
The final origin server destination may be the same in both tests, but<br>
the two transactions are completely different from Squid point of view.<br>
<br>
<br>
> ssl_bump peek step1 all<br>
> ssl_bump peek step2 allowed_https_sites<br>
> ssl_bump splice step3 allowed_https_sites<br>
> ssl_bump terminate step3 all<br>
<br>
<br>
AFAICT, this configuration is splicing or terminating all TLS traffic.<br>
No bumping at all. If you want your Squid to bump TLS tunnels, then you<br>
have to have at least one "bump" rule!<br>
<br>
I do not know what your overall SslBump needs are, but perhaps you meant<br>
something like the following?<br>
<br>
    acl shouldBeBumped ssl::server_name .<a href="http://amazonaws.com" rel="noreferrer" target="_blank">amazonaws.com</a><br>
<br>
    ssl_bump stare all<br>
    ssl_bump bump shouldBeBumped<br>
    ssl_bump terminate all<br>
<br>
Please do not use the configuration above until you understand what it<br>
does. Please see <a href="https://wiki.squid-cache.org/Features/SslPeekAndSplice" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/Features/SslPeekAndSplice</a><br>
for details.<br>
<br>
Depending on your environment, the http_access rules may need to be<br>
adjusted to allow CONNECT requests (to TLS-safe ports) to IP addresses<br>
that do not result in .<a href="http://amazonaws.com" rel="noreferrer" target="_blank">amazonaws.com</a> in reverse DNS lookups.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
</blockquote></div>