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