[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: eliezer at ngtech.co.il



-----Original Message-----
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 
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 at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev