[squid-users] Trying to set up SSL cache

[Amos Jeffries]

On 24/02/22 15:26, Dave Blanchard wrote:
> Hello, I'm trying to configure Squid as a HTTPS cache on my local computer, using ssl-bump. I've got it working as a basic proxy, but the traffic seems to just be tunneling through and not being cached.

Do you actually get at least *2* (maybe 3) Squid access.log entries per 
client connection demonstrating that?


> My web browser shows the site's actual certificate, rather than the locally generated self-signed certificate, which I want it to see. I have followed every tutorial I can find and none of them are helpful in figuring out what the hell is going on here. Here is what my config file looks like:
> 
> [...]
> 
> http_port 3128 ssl-bump \
>                 generate-host-certificates=on \
>                 dynamic_cert_mem_cache_size=32MB \
>                 cert=/path/to/self-signed.pem \
>                 key=/path/to/self-signed.pem
> 
> sslcrtd_program /usr/libexec/security_file_certgen -s /path/to/ssl-database -M 32MB
> 
> ssl_bump peek all

Okay TLS handshake clientHello gets observed by Squid.

At this point you should see 2 CONNECT requests in access.log, first 
(step1) with raw-IP and second (step2) with the TLS SNI from this 
clientHello (if any, otherwise raw-IP again).


> ssl_bump bump all

... now (step3) everything gets decrypted.

At this point you should start seeing access.log entries with https:// 
URLs and the actual server name per the serverHello certificate.


> ssl_bump splice localhost
> 

The connection is already bump'ed. This rule can never be reached.


> [...]
> 
> Otherwise, it's pretty much just the default config. The only thing that seems to halfway work is removing the line:
> 
> http_access deny CONNECT !SSL_ports
> 
> and changing to:
> 
> http_access deny CONNECT
> 

This actively rejects *all* CONNECT messages. Including the one Squid 
uses internally for SSL-Bump step1.


> With that change, an older Chromium just hangs trying to load the page, saying "Processing request." On a WebKit-based browser, I get a Squid 'Access Denied' error page.

As expected with a "deny CONNECT" rule on a CONNECT request.

This is actually the best outcome right now. It means the SSL-Bump 
crypto part is working fine for at least this second client.

What you need to do next is figure out which of your other rules is 
causing things to go wrong when the HTTP message inside the TLS is received.

For example; whether it is actually *HTTP/1* messages arriving. Other 
things will revert back to tunneling (see 
<http://www.squid-cache.org/Doc/config/on_unsupported_protocol/>)


> Another WebKit browser complains about the certificate, but when I tell it to continue anyway, it gives the same 'Access Denied' page.
> A newer Chromium stops right away with an untrusted SSL certificate error, and the details look like it's getting the self-signed certificate, as expected.
> 

These clients do not trust the CA Squid is using as signing cert. That 
will need to be fixed to avoid the cert complaint, but does not 
otherwise make any difference to the main issue.


You could use these browsers to test if you don't mind the popup. But I 
recommend the one which already trusts Squids signing CA until you have 
the rest of the basics working.



There are a few things to be aware of while troubleshooting:

* not all TLS connections can be bump'ed. TLS is designed to prevent 
exactly the type of decrypt that bump does. If the client and server are 
using TLS properly bump *will* fail.


* Google are known to be rather pedantic about security. So having their 
software at either end of the TLS when testing is more likely to hit 
such non-decryptable TLS connections.


* Checking the test web service for TLS certificate pinning or DANE. 
Both of these lock the/some client into using the original server 
certificate and they will unavoidably reject the Squid signing CA.

* Check traffic from the web server for HTTPS-Transport-Security or 
Alt-Svc HTTP headers. Both of these can break SSL-Bump if they reach a 
client. What is worse they can force arbitrarily long cache times for 
the info they contain, causing breakage to extend across the whole 
period. Only a full client purge of state and never receiving the info 
again can via any protocol fix these.


Amos