[squid-dev] [RFC] http(s)_port TLS/SSL config redesign
eliezer at ngtech.co.il
Thu Aug 10 00:39:56 UTC 2017
I have not used v4 yet but the arguments stand for themselves.
Linux System Administrator
Email: eliezer at ngtech.co.il
From: squid-dev [mailto:squid-dev-bounces at lists.squid-cache.org] On Behalf Of Amos Jeffries
Sent: Thursday, July 20, 2017 04:27
To: Squid Developers <squid-dev at lists.squid-cache.org>
Subject: [squid-dev] [RFC] http(s)_port TLS/SSL config redesign
Hi all, Christos and Alex particularly,
I have been mulling over several ideas for how to improve the config
parameters on the http(s)_port to make them a bit easier for newbies to
get right, and pros to do powerfully cool stuff.
So, the most major change I would like to propose is to move the proxies
CA for cert generation from cert= parameter to
generate-host-certificates= parameter. Having it configured with a file
being the same as generate =on and not configuring it default to =off.
The matching key= and any CA chain would need to be all bundled in the
same PEM file. That should be fine since the clients get a separate DER
file installed, not sharing the PEM file loaded into Squid.
That will stop confusing newbies have over what should go in cert= for
what Squid use-case. And will allow pros to configure exactly which
static cert Squid uses as a fallback when auto-generating others -
simply by using cert= in the normal non-bumping way.
Also, we can then easily use the two sets of parameters in identical
fashion for non-SSL-Bump proxies to auto-generate reverse-proxy certs
based on SNI, or use a fallback static cert of admins choice.
Bringing these two different use-cases config into line should vastly
simplify the complexity of working with Squid TLS certs for everybody,
including us in the code as we no longer have multiple (8! at least)
code paths for different cert= possibilities and config error handling
For backward compatibility concerns with existing SSL-Bump configs I
think we can use the certificate CA vs non-CA property to auto-detect
old SSL-Bump configs being loaded and handle the compatibility
auto-upgrade and warnings. The warning will be useful long-term and not
just for the transitional period.
Now would also be a marginally better than usual time to make the change
since the parameters are migrating to tls-* prefix in v4 and have extra
admin attention already.
squid-dev mailing list
squid-dev at lists.squid-cache.org
More information about the squid-dev