Configuration for security.

[Alan Conway <ac...@redhat.com>]

The problem:

1. Insecure defaults are, well, insecure.
2. Secure defaults cause confusion and support overhead esp. in dev/testing environments.
3. We need fine-grained security settings (e.g. "allow-plain-with-ssl") because security is complicated.

Here's what I would suggest:

Provide a top-level setting: "secure", default true.

If true, all the fine-grained security settings have secure defaults.
If false, all fine-grained security settings have permissive defaults.

This addresses the problems as follows:

1. We are secure by default.
2. User in a safe environment must set secure=off but that beats making them hit "allow-plain-with-ssl", "require-sasl-if-no-ssl", "no-ssl-verison-3-on-full-moon" ... one by one. It is also very clear that this is flat-out insecure. When the user is ready for security they will set secure=true and be less surprised if they have to tweak other security settings.
3. We have fine-grained settings to selectively permit special things in secure mode for people with special needs.

Cheers,
Alan.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

RE: Configuration for security.

[Steve Huston <sh...@riverace.com>]

I'm not aware of the goings on that prompted this topic, but FWIW, I think Alan's proposal is a really good approach.

> -----Original Message-----
> From: Alan Conway [mailto:aconway@redhat.com]
> Sent: Wednesday, May 06, 2015 10:29 AM
> To: Andrew Stitcher
> Cc: dev@qpid.apache.org; messaging@redhat.com
> Subject: Re: Configuration for security.
> 
> On Tue, 2015-05-05 at 14:57 -0400, Andrew Stitcher wrote:
> > On Tue, 2015-05-05 at 14:21 -0400, Alan Conway wrote:
> > > On Tue, 2015-05-05 at 12:43 -0400, Andrew Stitcher wrote:
> > > > On Tue, 2015-05-05 at 12:13 -0400, Alan Conway wrote:
> > > > > The problem:
> > > > >
> > > > > 1. Insecure defaults are, well, insecure.
> > > > > 2. Secure defaults cause confusion and support overhead esp. in
> dev/testing environments.
> > > > > 3. We need fine-grained security settings (e.g. "allow-plain-with-ssl")
> because security is complicated.
> > > > >
> > > > > Here's what I would suggest:
> > > > >
> > > > > Provide a top-level setting: "secure", default true.
> > > >
> > > > The new proton security APIs are pretty similar to this already -
> > > > you did look at them?
> > > >
> > > > There are actually 2 setting which control authentication and
> > > > encryption.
> > >
> > > That's what I'm getting at. There are already 2, you're adding
> > > another which is 3, then there'll be 4...
> >
> > I did consider those settings pretty carefully and did have them
> > reviewed (potentially by you).
> >
> > I do think they reasonably cover a lot of the security landscape in a
> > simple to understand way, and don't need adding to.
> >
> > However, if you want to add more detailed settings not covered by them
> > that's ok too.
> 
> OK, let me back up and regroup:
> 
> I'm happy with 2 settings auth_required, encryption_required. If we can
> satisfy all users with just those two I will be very happy.
> 
> I am not *proposing* additional settings, but I had the impression we were
> on the verge of adding one allow_plain_with_no_ssl or somesuch. If we can
> avoid that then so much the better.
> 
> IF we do (now or later) need to start adding detailed settings, then they they
> should have a sensible default *based on the values of auth_required and
> encryption_required*, not just a static default.
> 
> Most users should ONLY have to set auth_required and encryption_required
> and be confident that things will usually Just Work. In particular if both are
> false, then all details settings should have permissive defaults. If both are
> true then all detailed settings should have strict defaults. So a secure user
> can assume the standard "denied if not explicitly permitted" for the
> additional settings, and an insecure user can assume "anything goes" without
> having to set a bunch of individual settings.
> 
> But again, if we can satisfy all with just the 2 settings that is ideal and we
> should strive to minimize additional settings.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org For additional
> commands, e-mail: dev-help@qpid.apache.org

Re: Configuration for security.

[Jakub Scholz <ja...@scholz.cz>]

On Wed, May 6, 2015 at 5:09 PM, Andrew Stitcher <as...@redhat.com>
wrote:

> I agree with this restatement of your position 100% - user configurable
> settings are evil.
>

I assume you are talking mainly proton here and I'm not sure what would be
the impact on me as an user and owner of AMQP / Qpid based messaging
infrastructure.

But as a user, I see this differently. As far as I know, Qpid has no
concept for supporting older versions and doesn't seem to release any
security fixes for older versions. In case a security issue is discovered
... with detailed configuration options the users of older releases might
be able to secure their software just by re-configuring it. Without them,
they will have to wait for next release and will be most probably forced to
upgrade to new major release. If you look at the past year or two, for
example SSL/TLS had its fair share of issues like insecure SSL versions or
encryption algorithms.

>From this perspective I like the initial suggestion from Alan - to have a
top level setting to simplify the configuration and "change the defaults"
and at the same time have a fine grained control for those who need them.

J.

Re: Configuration for security (irrelevant musings)

[Alan Conway <ac...@redhat.com>]

On Wed, 2015-05-06 at 11:09 -0400, Andrew Stitcher wrote:
> On Wed, 2015-05-06 at 10:28 -0400, Alan Conway wrote:

> I agree with this restatement of your position 100% - user configurable
> settings are evil.

I like to think that user configurable settings are an admission of
failure by the developer. "I can't figure out what the code should do,
so I'll make the user tell me." Rarely does the developer stop to wonder
"If I, with access to all the code and run-time state of the program,
can't figure it out, how is the user going to?"




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: Configuration for security.

[Andrew Stitcher <as...@redhat.com>]

On Wed, 2015-05-06 at 10:28 -0400, Alan Conway wrote:
> ...
> > However, if you want to add more detailed settings not covered by them
> > that's ok too.

I should have been clearer here - At the top level (mostly in
pn_transport) I think that these two settings are sufficient for
everything I can think of. But if we need finer grain control then we
can add extra settings to the detailed objects pn_sasl/pn_sasl. There
are already detailed settings - mostly in pn_ssl to set the certificates
and verification policy. However for very many uses this should not be
necessary.

> 
> OK, let me back up and regroup:
> 
> I'm happy with 2 settings auth_required, encryption_required. If we can
> satisfy all users with just those two I will be very happy.
> 
> I am not *proposing* additional settings, but I had the impression we
> were on the verge of adding one allow_plain_with_no_ssl or somesuch. If
> we can avoid that then so much the better. 
> 
> IF we do (now or later) need to start adding detailed settings, then
> they they should have a sensible default *based on the values of
> auth_required and encryption_required*, not just a static default.
> 
> Most users should ONLY have to set auth_required and encryption_required
> and be confident that things will usually Just Work. In particular if
> both are false, then all details settings should have permissive
> defaults. If both are true then all detailed settings should have strict
> defaults. So a secure user can assume the standard "denied if not
> explicitly permitted" for the additional settings, and an insecure user
> can assume "anything goes" without having to set a bunch of individual
> settings.
> 
> But again, if we can satisfy all with just the 2 settings that is ideal
> and we should strive to minimize additional settings.
> 
> 

I agree with this restatement of your position 100% - user configurable
settings are evil.

Andrew


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: Configuration for security.

[Alan Conway <ac...@redhat.com>]

On Tue, 2015-05-05 at 14:57 -0400, Andrew Stitcher wrote:
> On Tue, 2015-05-05 at 14:21 -0400, Alan Conway wrote:
> > On Tue, 2015-05-05 at 12:43 -0400, Andrew Stitcher wrote:
> > > On Tue, 2015-05-05 at 12:13 -0400, Alan Conway wrote:
> > > > The problem:
> > > > 
> > > > 1. Insecure defaults are, well, insecure.
> > > > 2. Secure defaults cause confusion and support overhead esp. in dev/testing environments.
> > > > 3. We need fine-grained security settings (e.g. "allow-plain-with-ssl") because security is complicated.
> > > > 
> > > > Here's what I would suggest:
> > > > 
> > > > Provide a top-level setting: "secure", default true.
> > > 
> > > The new proton security APIs are pretty similar to this already - you
> > > did look at them?
> > > 
> > > There are actually 2 setting which control authentication and
> > > encryption.
> > 
> > That's what I'm getting at. There are already 2, you're adding another
> > which is 3, then there'll be 4...
> 
> I did consider those settings pretty carefully and did have them
> reviewed (potentially by you).
> 
> I do think they reasonably cover a lot of the security landscape in a
> simple to understand way, and don't need adding to.
> 
> However, if you want to add more detailed settings not covered by them
> that's ok too.

OK, let me back up and regroup:

I'm happy with 2 settings auth_required, encryption_required. If we can
satisfy all users with just those two I will be very happy.

I am not *proposing* additional settings, but I had the impression we
were on the verge of adding one allow_plain_with_no_ssl or somesuch. If
we can avoid that then so much the better. 

IF we do (now or later) need to start adding detailed settings, then
they they should have a sensible default *based on the values of
auth_required and encryption_required*, not just a static default.

Most users should ONLY have to set auth_required and encryption_required
and be confident that things will usually Just Work. In particular if
both are false, then all details settings should have permissive
defaults. If both are true then all detailed settings should have strict
defaults. So a secure user can assume the standard "denied if not
explicitly permitted" for the additional settings, and an insecure user
can assume "anything goes" without having to set a bunch of individual
settings.

But again, if we can satisfy all with just the 2 settings that is ideal
and we should strive to minimize additional settings.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: Configuration for security.

[Andrew Stitcher <as...@redhat.com>]

On Tue, 2015-05-05 at 14:21 -0400, Alan Conway wrote:
> On Tue, 2015-05-05 at 12:43 -0400, Andrew Stitcher wrote:
> > On Tue, 2015-05-05 at 12:13 -0400, Alan Conway wrote:
> > > The problem:
> > > 
> > > 1. Insecure defaults are, well, insecure.
> > > 2. Secure defaults cause confusion and support overhead esp. in dev/testing environments.
> > > 3. We need fine-grained security settings (e.g. "allow-plain-with-ssl") because security is complicated.
> > > 
> > > Here's what I would suggest:
> > > 
> > > Provide a top-level setting: "secure", default true.
> > 
> > The new proton security APIs are pretty similar to this already - you
> > did look at them?
> > 
> > There are actually 2 setting which control authentication and
> > encryption.
> 
> That's what I'm getting at. There are already 2, you're adding another
> which is 3, then there'll be 4...

I did consider those settings pretty carefully and did have them
reviewed (potentially by you).

I do think they reasonably cover a lot of the security landscape in a
simple to understand way, and don't need adding to.

However, if you want to add more detailed settings not covered by them
that's ok too.

A



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: Configuration for security.

[Alan Conway <ac...@redhat.com>]

On Tue, 2015-05-05 at 12:43 -0400, Andrew Stitcher wrote:
> On Tue, 2015-05-05 at 12:13 -0400, Alan Conway wrote:
> > The problem:
> > 
> > 1. Insecure defaults are, well, insecure.
> > 2. Secure defaults cause confusion and support overhead esp. in dev/testing environments.
> > 3. We need fine-grained security settings (e.g. "allow-plain-with-ssl") because security is complicated.
> > 
> > Here's what I would suggest:
> > 
> > Provide a top-level setting: "secure", default true.
> 
> The new proton security APIs are pretty similar to this already - you
> did look at them?
> 
> There are actually 2 setting which control authentication and
> encryption.

That's what I'm getting at. There are already 2, you're adding another
which is 3, then there'll be 4...

Hence the idea of a *single* boolean "secure" setting that gives you
"fully secure" or "fully permissive" by default and lets you pick if you
want to change any specific item.

With that, it's reasonable to default secure=on, since it's trivial for
the developer to turn it off. The secure user will be happy that it is
secure by default and they have control of the details.

If you have a bunch of individual settings with no single control the
secure user will run away screaming if they're insecure by default. If
they're secure by default the developer will trip over them one by one
and limp away swearing.

>  By default neither are required which is the insecure
> setting, but you can individually turn them on, so a better security
> level for a server would be:
> 
>   pn_transport_require_auth(transport, true);
>   pn_transport_require_encryption(transport, true);
> 
> The reason to be permissive by default is exactly to make it easier for
> new developers (although Robbie didn't especially agree).
> 
> Currently at the server end PLAIN us disabled unless you are using SSL -
> but the client will use PLAIN if it is offered and it is the most secure
> option.
> 
> I think it would make sense to control whether PLAIN is allowed without
> SSL by also hanging it off the require_auth flag, so that it would be
> allowed by default too. The logic here is that PLAIN without SSL is
> actually about as secure as unauthenticated as you can never be sure who
> is sniffing your packets and capturing your password.
> 
> There could certainly be a finer grain setting if people wanted it
> though.
> 
> Andrew
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

Re: Configuration for security.

[Andrew Stitcher <as...@redhat.com>]

On Tue, 2015-05-05 at 12:13 -0400, Alan Conway wrote:
> The problem:
> 
> 1. Insecure defaults are, well, insecure.
> 2. Secure defaults cause confusion and support overhead esp. in dev/testing environments.
> 3. We need fine-grained security settings (e.g. "allow-plain-with-ssl") because security is complicated.
> 
> Here's what I would suggest:
> 
> Provide a top-level setting: "secure", default true.

The new proton security APIs are pretty similar to this already - you
did look at them?

There are actually 2 setting which control authentication and
encryption. By default neither are required which is the insecure
setting, but you can individually turn them on, so a better security
level for a server would be:

  pn_transport_require_auth(transport, true);
  pn_transport_require_encryption(transport, true);

The reason to be permissive by default is exactly to make it easier for
new developers (although Robbie didn't especially agree).

Currently at the server end PLAIN us disabled unless you are using SSL -
but the client will use PLAIN if it is offered and it is the most secure
option.

I think it would make sense to control whether PLAIN is allowed without
SSL by also hanging it off the require_auth flag, so that it would be
allowed by default too. The logic here is that PLAIN without SSL is
actually about as secure as unauthenticated as you can never be sure who
is sniffing your packets and capturing your password.

There could certainly be a finer grain setting if people wanted it
though.

Andrew



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org