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

Mon, 2 Mar 2015 23:13:30 +0200

Hmmm, when you buy a car, what if you could choose not to install safety bel=
ts 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 hig=
h market value for that.=20

Just a thought :)

Br, jukka

Sent from my iPhone

> On 1.3.2015, at 20.59, Troy Benjegerdes <hozer@hozed.org> wrote:
>=20
>> 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.
>>>=20
>>> 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.
>>=20
>> 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.
>=20
> Agreed.
>=20
> 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=20=

> able to advertise that all connections are encrypted by default, and *only=
*
> the Kerberos server has access to the keys.=20
>=20
> (I am not a fan of the https/ssl public/private key model where any attack=
er
> can buy a root cert, or pre-install it on laptops)
>=20
> 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=20=

> require public/private keys to do correctly.
>=20
>=20
>>> (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 findi=
ng
>>> the documentation and enabling encryption everywhere.
>>=20
>> Agreed.
>>=20
>>> 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".
>>=20
>> 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.
>>=20
>>> 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:
>>>=20
>>> (1) Is it sufficient to have one single knob that controls all connectio=
ns
>>> from a given host, whether cache manager or server?
>>=20
>> Unlikely.
>>=20
>>> (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?
>>=20
>> One knob per service with a host configurable default.
>>=20
>>> (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.)
>>=20
>> 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.
>>=20
>> There should be a service configurable knob with a configurable default.
>> The default should be "crypt".
>>=20
>>> 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 positi=
on
>>> of the community as a whole.
>>=20
>> I believe this is a topic in which every organization that deploys
>> OpenAFS should speak up.
>>=20
>>>=20
>>> Thank you,
>>>=20
>>> Ben
>>>=20
>>>=20
>>> (*) 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.
>>=20
>> 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.
>>=20
>> Jeffrey Altman
>=20
>=20
>=20
> --=20
> --------------------------------------------------------------------------=
--
> Troy Benjegerdes                 'da hozer'                  hozer@hozed.o=
rg
> 7 elements      earth::water::air::fire::mind::spirit::soul        grid.co=
op
>=20
>      Never pick a fight with someone who buys ink by the barrel,
>         nor try buy a hacker who makes money by the megahash
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info