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

[Adam Majer]

On 02/02/2018 11:08 AM, Eliezer Croitoru wrote:
> 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


squid-4 will be in openSUSE Leap 15 and SLE-15 for various reasons,
mainly because of OpenSSL 1.1 requirements. April-ish timeline is also
important for openSUSE, not just Ubuntu. It would be nice to have
official non-beta versions. ;)

- Adam
___
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

[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: 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: squid-dev@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@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

___
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

[Amos Jeffries]

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@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

[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