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

[Eliezer Croitoru]

Great to hear about this.

The RPM's for 4.0.x latest already built and I'm starting to work on the near step towards which I hope is 4.1.0.
I hope that by 4.1 I will have packages for Debian 9.
Are we expecting 4.1 to be released sooner then Ubuntu 18.04 LTS(April 2018)?

* https://wiki.ubuntu.com/Releases

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, February 1, 2018 15:11
To: squid-dev at lists.squid-cache.org
Subject: Re: [squid-dev] [RFC] http(s)_port TLS/SSL config redesign

The final part of the proposal quoted below are now PR'd for audit.

There are several differences from the initial proposal;

* the ServerOptions::signingCa class changes and new default for
generate-host-certificates have allowed a far simpler back-compat check
using the non-existence of a filename by generate-host-certificates=
instead of relying on cert CA checking.
 That CA checking should still be done, but is no longer a required part
of this project.

* generation of reverse-proxy certificates is happening in a separate
parallel project.


Amos


On 20/07/17 13:27, 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.
> 
> 
> 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
_______________________________________________
squid-dev mailing list
squid-dev at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev