Hmmm, when you buy a car, what if you could choose not to install safety belts at all, install ones made of toilet paper or safe ones...?
What if OpenAFS would be known to be safe? I agree that there would be a high market value for that. Just a thought :) Br, jukka Sent from my iPhone > On 1.3.2015, at 20.59, Troy Benjegerdes <[email protected]> wrote: > >> On Sat, Feb 28, 2015 at 02:28:17PM -0500, Jeffrey Altman wrote: >>> On 2/27/2015 3:26 PM, Benjamin Kaduk wrote: >>> One change which has been proposed is to encrypt connections by default. >>> There has long been the 'fs setcrypt' command (introduced in 2001) to >>> allow the connections from a cache manager to the servers in the cell >>> (which most distributions' packaging enable by default). However, there >>> is not currently an option to enable encryption for the intra-dbserver >>> connections which effect ubik replication, or for other server-to-server >>> connections such as fileserver queries to the protection server, and >>> volume forwarding traffic. >>> >>> Given events in the news in recent years, it seems to me that we do our >>> users a disservice by not using a "secure" mode operation by default. >> >> Agreed. I am particularly troubled by the lack of wire privacy mode >> used for volume transfers and since organizations replicate volume data >> across the public Internet between sites and it never occurs to them >> that this data might be sent in the clear. > > Agreed. > > It is particularly irritating to have to set up a VPN to replicate volume > data. It would be a particularly compelling market advantage of AFS to be > able to advertise that all connections are encrypted by default, and *only* > the Kerberos server has access to the keys. > > (I am not a fan of the https/ssl public/private key model where any attacker > can buy a root cert, or pre-install it on laptops) > > Someday I would like to see per-file (or maybe per-volume) encryption keys, > and keep the decryption keys separate from the data. That might actually > require public/private keys to do correctly. > > >>> (Quote around "secure" are necessary given the known weaknesses of the >>> fcrypt encryption used by rxkad, but with the rxkad-k5 extension, there >>> does remain some level of protection to offer.) Though rxkad encryption >>> is known to introduce severe performance penalties, administrators who >>> require the extra performance should be able to discover that and use >>> the documented procedure for disabling encryption. Administrators who >>> just want to set something up and have it running would be protected, >>> without needing to know that they need to go through the effort of finding >>> the documentation and enabling encryption everywhere. >> >> Agreed. >> >>> I propose that the OpenAFS 1.8 major release introduce encryption by >>> default, for all(*) connections, whether client-to-server or >>> server-to-server. There would of course be knobs to disable encryption >>> for sites which do not need it, but the default value would be "on". >> >> It is worth pointing out that the Windows client has defaulted to crypt >> mode since I began working on it in 2003. If I had my way at the time >> crypt mode would be required and not configurable. Still to this day I >> hear from administrators that they have no need to security because the >> cell is internal. This simply isn't true. It is not possible to keep >> attackers out all of the time. If the major banks that spend billions >> on IT cannot do it, neither can an organization that deploys OpenAFS. >> >>> In addition to feedback on the general proposal for encrypt-by-default, I >>> would appreciate feedback on more detailed questions, which might shape >>> the structure of an implementation: >>> >>> (1) Is it sufficient to have one single knob that controls all connections >>> from a given host, whether cache manager or server? >> >> Unlikely. >> >>> (2) (Assuming that the answer to (1) is "no") Should there be separate >>> knobs knob for intra-ubik connections, fileserver-to-ptserver, and >>> volserver-to-volserver connections? >> >> One knob per service with a host configurable default. >> >>> (3) What downsides do you see as possible for a new text-based >>> configuration file to control the various behaviors? (Looking forward, >>> this could also be a place to configure selection of rxgk vs. rxkad.) >> >> The source tree imports the Heimdal krb5 profile configuration parser. >> There was agreement at the last Pittsburgh hackathon on a format. Mike >> Meffie was scribe. The AuriStor configuration is based upon that model >> as presented at the CERN conference. OpenAFS should do the same. >> >> There should be a service configurable knob with a configurable default. >> The default should be "crypt". >> >>> No decisions have been made; this thread is me seeking feedback from the >>> community on an issue where I have an opinion but do not know the position >>> of the community as a whole. >> >> I believe this is a topic in which every organization that deploys >> OpenAFS should speak up. >> >>> >>> Thank you, >>> >>> Ben >>> >>> >>> (*) My current proposal affects mostly the cache manager; >>> encryption-by-default for the standalong client tools (vos, pts, bos, >>> etc.) would be configurable in a different way, presumably with a >>> command-line option. >> >> At least some of the command line tools already have a -crypt option. >> The Windows client enables crypt by default unless the cache manager's >> crypt setting has been disabled. >> >> Jeffrey Altman > > > > -- > ---------------------------------------------------------------------------- > Troy Benjegerdes 'da hozer' [email protected] > 7 elements earth::water::air::fire::mind::spirit::soul grid.coop > > Never pick a fight with someone who buys ink by the barrel, > nor try buy a hacker who makes money by the megahash > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
