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. > (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
smime.p7s
Description: S/MIME Cryptographic Signature
