On 13/05/17 14:33, Masha Lifshin wrote:
Dear Squid Users list,
I have a Squid 4 configured as explicit proxy with ssl-bump
interception. I am working on making it as secure as possible, given
the vulnerability risks with doing ssl inspection
(https://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html).
I am implementing the hardening suggestions at
http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
One other feature I have found is the SSL Server Certificate
Validator. As far as I understand one can write a helper that
performs additional certificate validation checks that squid doesn't
perform out of the box?
Yes. However, do not expect to use it as an alternative to what Squid
already validates. Disabling validation (eg the DONT_VERIFY_* flags)
includes disabling use of the helper as well.
Does anyone know of any widely agreed upon open source helpers, or
is this something where people are rolling their own?
AFAIK this is something a very few people are implementing on their own.
Squid validates the whole cert chain using the normal OpenSSL library
mechanisms regardless of this helper, so it is most useful for unusual
types of checks (eg DANE).
Are there other configuration options that can help? I am curious
what else others in the community are doing along these lines, and if
there are recommended best practices in the squid community? I
appreciate your insights.
The features are still under constant development, so best practices are
almost as volatile as the code. The basics I'm recommending for now are:
0) don't bump. treat it as a last resort.
1) use cert mimic to pass problems on to the client.
2) avoid client-first and equivalent (step1) bumping.
3) follow TLS best practices to harden.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users