[squid-dev] [RFC] http(s)_port TLS/SSL config redesign

[Alex Rousskov]

On 07/19/2017 07:27 PM, Amos Jeffries wrote:
> 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
> permutations.
> 
> 
> 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.


I doubt I can grasp all the side effects, but what you are proposing
sounds very good to me in principle. If your arguments are valid, then I
would go further, for exactly the same reasons you are giving above: I
suggest deprecating abused cert/key pair and having a new option for the
regular _port certificate/key. For example:

  https_port port-certificate=... generate-host-certificates=...

and then I would also deprecate generate-host-certificates instead of
abusing a boolean option to specify an essentially required argument,
arriving at something like this:

  https_port port-certificate=... ssl-bump-ca-certificate=...

and refuse to accept non-CA certificates in ssl-bump-ca-certificate.

The "port-" prefix can be dropped but I think having two different
prefixes for two certificates is better.


HTH,

Alex.