Search squid archive

Re: Trying to set up SSL cache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux