qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Configuration for security.
Date Tue, 05 May 2015 18:21:54 GMT
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

View raw message