[squid-users] Best practices for beefing up security for squid with ssl-bump

Amos Jeffries squid3 at treenet.co.nz
Sat May 13 12:36:08 UTC 2017

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.


More information about the squid-users mailing list