[OpenAFS] Encrypted connections by default in OpenAFS 1.8?

[Jason Edgecombe]

On 02/27/2015 03:26 PM, Benjamin Kaduk wrote:
> Hi all,
>
> The progress towards a 1.8 release is well underway, and it is time to
> consider what behavior changes are desired for the major release boundary.
>
> 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.
> (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.
>
> 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".
>
> 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?
>
> (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?
>
> (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.)
>
>
> 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.
>
> 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.
I suggest the following knobs:
* client
  ** fs set crypt
  ** option/config file for vos and friends if they can't read 'fs getcrypt'
* server
** file server option to force authenticated access to use encryption
** option to force/disable encryption for ubik
** option to force/disable other server-to-server stuff

I wouldn't object to having knobs for the ptserver-fileserver and 
volserver connections, but I don't see much point. As an admin, I look 
at this according to the likely upgrade scenarios and exposure. I tend 
to upgrade in batches of clients, file servers, and cell servers. I 
think the biggest exposure, in an on-premise set up, is 
client-to-fileserver. server-to-server traffic is often on at least a 
semi-trusted network.