[tahoe-dev] can the web browser be used securely to manage your data? Re: Tahoe-LAFS is widely misunderstood

[Greg Troxel]

"Zooko O'Whielacronx" <zooko at zooko.com> writes:

> Our fix for Nathan's exploit was to remove a convenience feature which
> provided ambient authority in order to reduce the user's exposure to
> visible capabilities. (That convenience feature was a URL path
> "http://$HOST/vdrive/" which the gateway would map to your root
> capability for you. This is exactly like the "tahoe:" alias that we
> later added to the CLI, except for the WUI.)
>
> Now, perhaps you, gentle reader, will draw a different lesson from the
> same empirical evidence. If you draw your alternative lesson well
> enough, you can win your own “I Hacked Tahoe-LAFS!” t-shirt. :-)

The WUI issue is related to another cap-handling issue, and I think it
helps to talk about them together.  Normally, one uses local unix
permissions and stores a rootcap in .tahoe/private/aliases.  But the
rootcap is really akin to one's passphrase to mount a cfs volume (or
truecrypt/encfs, for those not as old as I am).  So leaving it in the
local filesystem is really only one security model which says: I don't
trust the cloud, but I do trust the hosts from which I access tahoe.

In many ways this is the only sane position, but there's a big
difference between "this machine doesn't have a keylogger" and "my caps
are on this machines backup tapes".

So, there probably should be some way to unlock caps protected with a
passphrase, much like ssh-agent or gpg-agent.  Then, the way caps are
used in browsers becomes obviously more problematic: in typical usage
the browser remembers caps and stores them in .mozilla/firefox/blah/blah
somepalce.

An interesting step would be to change the WUI to treat capabilities as
passwords rather than form values.   My two worries are:

  firefox remember caps by default

  firefox is too big to be non-scary to handle secrets.  sometimes it's
  too hard to resist, but tahoe doesn't feel architecturally like one of
  those times.



So a valid attack would be:

  get control of a computer on which someone has used tahoe in the past
  (accessing the WUI with a browser), and get at their files.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110203/aa518c8d/attachment.pgp>