[squid-users] How to have squid as safe as (e.g.) firefox?
squid3 at treenet.co.nz
Wed Aug 19 17:09:40 UTC 2015
On 20/08/2015 3:43 a.m., Jeremie Rafin wrote:
> Amos and Alex,
> Thanks a lot for all your advises. I appreciate your helpful comments! :))
> Nevertheless, all is not cristal clear for me. I have setup a sandbox (virtual box with squid 3.5.7 on debian 7.6; for transparent proxy, I have setup NAT iptables and IP route to run client through squid; my client browser is configured with squid certificate) and have tried many configurations. I am still a little bit lost...
> Let me sum-up my needs, first. In a family context, I would like:
> -a) to black/white list accesses (with e.g. squidguard);
Use ufdbguard if you actually have to have one of these. SG is a dead
Or just use an ACL blacklist/whitelist in squid.conf. Far simpler.
> -b) to check for content (with e.g. diladele or e2guardian);
Use an ICAP / eCAP service instead. It will greatly simplify your next
requirements implementation ...
> -c) to do that for https (because more and more sites cipher links, like google);
> -d) not to check for content for a given (spliced) sites (like banks);
> -e) not to degrade security; for instance, revoked CA must not succeed in access, even if bumped;
> -f) [nice to have]: to do this in a transparent proxy way; but explicit proxy would also be ok, if required.
> Second, as per your advises, and some searches, I have setup this configuration (from the default one, unchanged; no third party, yet):
> # Black list: meteofrance (http) and google (https)
> acl blacklist dstdomain .meteofrance.com
> acl sslblacklist ssl::server_name .google.fr
> http_access deny blacklist
> http_access deny sslblacklist
Is that "sslblacklist" test in http_access actually matching?
I didn't think we had ssl_server_name working outside the ssl_bump rules
yet. Good news if we do.
> # Non bumped list (only spliced): wellsfargo
> acl splicelist ssl::server_name .wellsfargo.com
> # SSL configuration
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> ssl_bump peek step1 all
> ssl_bump splice step2 splicelist
> ssl_bump bump all
> # Web access
> http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myCA.pem
> http_port 3126 intercept
> https_port 3127 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/myCA.pem
> sslcrtd_program /usr/local/squid-3.5/lib/squid/ssl_crtd -s /var/spool/squid3_ssldb -M 4MB
> With this config file, I am able to satisfy my requirements a, b
(ready for), c, d and f (I mean a, b, c and d are ok in transparent and
explicit modes). But e fails: https://revoked.grc.com/ is not rejected.
> So, even if I think my configuration is much cleaner thanks to you
(you will probably comment), I have still the same feeling of degrading
the security when bumping. Hence, my main question remains (title of the
thread): how to get (at least) revocation working (requirement "e")?
I was about to suggest the CRL file loading option. But I see that
Squid-3 did not actually expose that option in squid.conf, even though
the code behind it was present. I guess that is another new config
feature coming in Squid-4 then, since its now possible.
For now in 3.5 there is still the cert validator helper. Should be
possible through that I think.
> During my investigation, I have met some other difficulties (these
points are less important than above main question, but are still obscur
> -"peek"/"splice"/"bump": nothing is logged in access.log (I tried a
"debug_options ALL,9"; no success); I have read in some post that
nothing is logged yet, but I double check: is it planed (or done) to get
log for SSL decision?
I hoping it will be eventually. But Christos appears to be concentrating
on getting the underlying security operations working well and finalized.
> -with this SSL configuration:
> # SSL configuration
> ssl_bump splice splicelist
> ssl_bump bump all
> -all works but **only in explicit proxy**; in transparent, the HTTPS are failing (no certification???); if I add a "ssl_bump peek all" before the "bump" rule, all https accesses are peeked (poken?) or spliced; nothing is bumped (in explicit and transparent); is it normal?
> -furthermore, google is not blacklisted **only** in transparent mode! Why?
> -the wiki (http://wiki.squid-cache.org/Features/SslPeekAndSplice) does not mention this need of step1/step2 (like first configuration) for having splice/bump decision working well in transparent mode, does it?
> -I noticed a quite similar unexpected behavior for "ssl_bump terminate" without "step1/step2"; for instance, a simple "ssl_bump terminate all" gives:
> -in transparent mode: no effet (no bump, no black list), all is spliced (or poken);
> -in explicit mode: google is rejected but every other https works (in a non bumped way);
> Note that "terminate" behaves logically (i.e. as I would expect) with a preceeding "acl step1 at_step SslBump1/acl step2 at_step SslBump2/ssl_bump peek step1 all". With "all" or, for instance, with "sslblacklist".
The page is outdated, essentially unchanged from when the whole feature
was a wishlist plan and no actual code. So it does not reflect much of
what the latest code actually does when bugs and workaround hacks are
There is another patch coming down to 3.5 in the next few days which
will resolve a lot of the little oddities in the actions selected. It
should make the behaviour more accurately follow that documentation.
<snip, but remembering the feedback for later>
>>> # Hide PROXY
>>> via off
>>> forwarded_for delete
>> Does *not* hide the proxy.
>> Hides the *client* by actively "shouting" the proxy details out to the
>> world in protocol places where the client details would normally go.
> This is another interesting topic -maybe not the right place here.
> The goal is to get video streaming: some web sites refuse to provide video if a proxy is detected (because of broadcast laws); to debug I use these sites (streaming web site is very slow):
> The only configuration I have found to hide the proxy (and to get the video streaming) was the above one. If you have a better configuration, I would be curious to know it: all of the configurations I found on internet was failing (and I was not able to find something else that works).
> Thanks :)
"forwarded_for transparent" (rather than delete. A tool can test for a
proxy deleting XFF).
Plus TPROXY. But that is another complex feature almost as tricky as
ssl_bump for some OS. So get one sorted out before mixing the other in.
Each time you bump a TLS certificate though, you will expose the proxy
via it too. Which can be tested for if the origin gets desperate to
prevent HTTP working properly (proxy support is a non-optional part of
More information about the squid-users