> Do you reckon your "Better SSL" stuff for 3.6 will make it practical > for not-in-depth-encryption-experts to use? eg our normal everyday > SysAdmin audience > > The greater public awareness of encryption from the NSA's badness > might make this a very useful useful thing. Both in practical terms > and for general marketing. > > Especially if we can make the docs around it simple to follow, so > that the less experienced admins out there can get it working right. As it is right now, the SSL stuff is hard to use even for developer types. My goal for this week is to fix that, by providing easy to use scripts around the rather cryptic OpenSSL commands to generate keys and certificates. Unfortunately, *distributing* those keys and certificates securely is always going to be a bit of a problem. Somewhere, somehow, someone has to enter a password that is turned into a key that is used to secure a session in which that material gets transferred. That's going to be a weak point. I think the best we can do is ensure forward secrecy; anyone who's not able to intercept traffic *at that precise moment* will be unable to do so at any subsequent time. The other problem is that glusterd can't handle the multi-threaded transport that goes with SSL. I'm trying to figure out whether running with SSL but a single transport thread - a very lightly tested combination because it would be a terrible idea for the I/O path - will work. If I can get that to work, glusterd will use SSL *by default* so that we get strong authentication. If the I/O path stuff is also easier to use, then I do think it's a positive differentiator worth crowing about. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
