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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
