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: elie...@ngtech.co.il -----Original Message----- From: squid-dev [mailto:squid-dev-boun...@lists.squid-cache.org] On Behalf Of Amos Jeffries Sent: Thursday, February 1, 2018 15:11 To: email@example.com 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 > firstname.lastname@example.org > http://lists.squid-cache.org/listinfo/squid-dev _______________________________________________ squid-dev mailing list email@example.com http://lists.squid-cache.org/listinfo/squid-dev _______________________________________________ squid-dev mailing list firstname.lastname@example.org http://lists.squid-cache.org/listinfo/squid-dev