[tahoe-dev] tahoe now has an FTP server!

[Nathan]

On Wed, Nov 26, 2008 at 4:10 PM, Brian Warner
<warner-tahoe at allmydata.com> wrote:
> On Mon, 24 Nov 2008 09:37:02 -0800
> Nathan <nejucomo at gmail.com> wrote:
>

[snip...]

>> If I did, would the result differ much from the WUI interface in its
>> security model?
>
> Well, assuming that you didn't create some sort of catch-all "public"
> directory for all anonymous users to use, the only thing an anonftp user
> could do is cd to a magic /uri/DIRCAP directory (not unlike the "visit a file
> or directory by uri" box on the WUI's welcome page). Once there, they could
> examine files as they please, and (if the cap is RW) upload files or make new
> subdirectories.
>
> The "user account" is really just an alias for an initial directory.

To me it sounds like there are two functional differences:

FTP users cannot create nameless files or directories, whereas a web user can.

The FTP interface provides a map of (username, password) -> dircap.
The web interface does not.


If you'll notice, the non-capabilities mapping of the latter
difference seems quite similar to the abandoned /vdrive WUI namespace,
and I'm afraid it may have similar security concerns.


Here's the scenario I am imagining (and next time I get a chance I'll
cook up a test case):

a. The victim's tahoe node provides an ftp interface.
b. The victim is using a web browser which has authenticated
themselves to the ftp interface, and the browser caches the
credentials (notice how this is like the ambient authority of a
session cookie).
c. The attacker creates an html + javascript file which detects that
the URL is ftp, then it spiders the private directory tree of the ftp
interface, operating on the files at whim, according to the
capabilities present in reachable directories.


This seems to throw a monkey-wrench in the non-anonymous ftp
interface, unless I am missing something.  Even the browser may not
allow write operations to FTP, the attack script can read the victim's
write caps then ship them off to a receiver http server for the
attacker to harvest.

The anonymous-only access case seems to me to have the same properties
as a read-only http interface to the same tahoe node.


Even when the user credentials are not cached by the browser, I'd bet
many users would gladly enter their "Tahoe credentials" when prompted
in the middle of using the Tahoe WUI.  IMO we should keep any notion
of username/password out of Tahoe so that, from a usability
standpoint, users are trained to think about caps more directly.

[snip...]

> It goes without saying that if you care about the confidentiality of your
> data or the integrity of your account, you won't access it over FTP, because
> everything is unencrypted. The only way I could recommend using tahoe's FTP
> server is via localhost.

The same holds true for the HTTP interface.

Likewise both of these interfaces could leverage SSL if the deployment
scenario wanted to rely on PKI.


>
>> Do tahoe devs envision deploying this username/password access scheme
>> elsewhere?  (For instance, optionally in the WUI?)
>
> Eh, maybe. As you know, I'm a fan of the capabilities model, and adding a
> username/password scheme would tend to obscure the underlying security model.
> So I'm not inclined to add anything to Tahoe beyond what's necessary for the
> allmydata business model.
>
> The main issue is: who gets to see your dircaps? If the WUI acquires this
> sort of thing, that means both Alice and Bob may be using some webapi node to
> access their files, and that webapi node now gets to see both of their
> dircaps. In addition, it means that Alice and Bob don't remember their own
> dircaps, but instead they rely upon some external login service to remember
> them, which means the login service also gets to see their data.
>
> To remain safe from this sort of eavesdropping, I encourage Tahoe users to
> run their own node, and to manage their own root dircaps. If you're doing
> that, then the "login" phase is just extra noise.


I certainly agree, which is why the FTP account scheme rubs me wrong.


> cheers,
>  -Brian
>


Nejucomo