[OpenAFS-devel] Re: [OpenAFS] Encrypted connections by default in OpenAFS 1.8?

[Troy Benjegerdes]

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'                  hozer@hozed.org
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