On Wed, Nov 26, 2008 at 4:10 PM, Brian Warner <[EMAIL PROTECTED]> wrote: > On Mon, 24 Nov 2008 09:37:02 -0800 > Nathan <[EMAIL PROTECTED]> 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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
