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

[Eliezer Croitoru]

I have not used v4 yet but the arguments stand for themselves.
+1

Eliezer


Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



-Original Message-
From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of 
Amos Jeffries
Sent: Thursday, July 20, 2017 04:27
To: Squid Developers 
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 
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.


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.


Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev

Re: [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.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev