[tahoe-dev] report of an unsuccessful assault on our fortress

[Brian Warner]

>> For example, when serving HTML files from the WUI, serve them from a
>> different origin (hostname:different-port,
>> ip-instead-of-hostname:same-port,
>> ip-instead-of-hostname:different-port, et c.).
> 
> This would be a promising solution to our problem, if we could
> persuade the browser that every file loaded from the tahoe-lafs web
> gateway should be each its own separate origin. But practically
> speaking -- how? Listen on thousands of ports? We might run out of
> ports.

Incidentally, this is mostly how the mozilla bugtracker ("bugzilla")
delivers attachments: https://bugzilla.mozilla.org/show_bug.cgi?id=123
has links to https://bug123.bugzilla.mozilla.org/attachment.cgi?id=789 .
Each ticket gets a separate origin (all of which map to the same actual
IP address, via a wildcard DNS record, so only one TCP port is
consumed). The *.bugzilla domains don't accept any interesting POST
commands, so there's no authority to be stolen, and each ticket gets a
different origin, so active content from one ticket cannot examine
content from a different ticket (perhaps ticket 1 is security-sensitive
and thus not publically visible, but ticket 2 has an attachment that
tries to read the contents of ticket 1).

We've kicked around the idea of using this for Tahoe, but we can't
safely rely upon an external DNS server to give us the wildcard mapping.
(we could host a DNS server which maps *.content.tahoe-lafs.org to
127.0.0.1, but then user filecaps would become vulnerable to us or
anyone who can interfere with their DNS requests).

The most promising approach I've heard so far is to map the
storage-index to an A/B/C triple and serve file-download/view links
pointing at 127.A.B.C . Most machines will treat all of those as the
same loopback interface, so the server shouldn't need to do anything
special.

(It might be better to randomly choose an A/B/C triple each time we
render a directory page, rather than using a deterministic mapping, to
deny attackers the ability to find a collision between their evil
document and the one they want to steal/manipulate. But that would make
it hard for me, since I run NoScript, to grant JS privileges just to
Zooko's blog and not to other documents. So it might be even better to
key the mapping with a per-webapi-server private seed, so that you get a
consistent-but-unpredictable mapping that an attacker can't exploit
without an online collision-finding attack.)

The overall idea would be to make sure that the main Tahoe page (on
127.0.0.1:3456) never displays unescaped user-generated content. All
filenames (even in error messages.. good catch!) must be escaped, and
all file content must be delivered from a different origin. The
unique-IP trick is then to protect content from other content.

cheers,
 -Brian