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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users