tahoe-lafs/trac

Hiding introducer and helper furls and other private info reported by a node on its web interface #860

New issue

Closed

opened 2009-12-16 05:27:02 +00:00 by daira · 12 comments

daira commented

2009-12-16 05:27:02 +00:00

(http://allmydata.org/pipermail/tahoe-dev/2009-December/003334.html)

Reported by Jody Harris:

I have a helper configured on a server, which turns out to be fantastically helpful. The one downside is that it reports its introducer furl on the HTML web interface. This is a problem for a "private" grid.

Is there a way to hide the introducer furl?

(http://allmydata.org/pipermail/tahoe-dev/2009-December/003334.html) Reported by Jody Harris: > I have a helper configured on a server, which turns out to be fantastically helpful. The one downside is that it reports its introducer furl on the HTML web interface. This is a problem for a "private" grid. > Is there a way to hide the introducer furl?

daira added the

labels 2009-12-16 05:27:02 +00:00

daira added this to the undecided milestone 2009-12-16 05:27:02 +00:00

imhavoc commented

2009-12-17 04:01:11 +00:00

Owner

(Comments from #861)

Any node that is available on an exposed IP address publishes the introducer furl and the helper furl (if attached) to the world.

This results in anyone discovering the address of an exposed node being able to attach to a grid and a helper. This could result in unlimited abuse.

If one wanted to store files on their grid, then publish specific files to the net, a public node is required. Once that node is published, finding the furls is trivial.

Example: Zooko's blog hosted on the TestGrid:
http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#2009-12-15

Going to the root of the node: http://testgrid.allmydata.org:3567/

Introducer:

pb://todjw7qkb4dgq4fkeo7cqydcu5vneioh@tahoecs2.allmydata.com:52106/introducer
Connected to introducer?: yes

This happens to be a wonderful feature for the TestGrid, but a easy point of attack for anyone with a "closed" or "limited" grid.

(Comments from #861) Any node that is available on an exposed IP address publishes the introducer furl and the helper furl (if attached) to the world. This results in anyone discovering the address of an exposed node being able to attach to a grid and a helper. This could result in unlimited abuse. If one wanted to store files on their grid, then publish specific files to the net, a public node is required. Once that node is published, finding the furls is trivial. Example: Zooko's blog hosted on the [TestGrid](wiki/TestGrid): <http://testgrid.allmydata.org:3567/uri/URI:DIR2-RO:j74uhg25nwdpjpacl6rkat2yhm:kav7ijeft5h7r7rxdp5bgtlt3viv32yabqajkrdykozia5544jqa/wiki.html#2009-12-15> Going to the root of the node: <http://testgrid.allmydata.org:3567/> Introducer: ``` pb://todjw7qkb4dgq4fkeo7cqydcu5vneioh@tahoecs2.allmydata.com:52106/introducer Connected to introducer?: yes ``` This happens to be a wonderful feature for the [TestGrid](wiki/TestGrid), but a easy point of attack for anyone with a "closed" or "limited" grid.

daira commented

2009-12-17 04:11:04 +00:00

Author

Replying to imhavoc:

This results in anyone discovering the address of an exposed node being able to attach to a grid and a helper. This could result in unlimited abuse.

Actually it shouldn't affect file confidentiality or integrity (so the keywords of this bug -- "privacy security" -- are correct). I agree it needs to be fixed.

Replying to [imhavoc](/tahoe-lafs/trac/issues/860#issuecomment-374843): > This results in anyone discovering the address of an exposed node being able to attach to a grid and a helper. This could result in unlimited abuse. Actually it shouldn't affect file confidentiality or integrity (so the keywords of this bug -- "privacy security" -- are correct). I agree it needs to be fixed.

daira changed title from ~~Hiding the introducer furl reported by a helper~~ to Hiding the introducer and helper furls reported by a storage server on its web interface

2009-12-17 04:11:04 +00:00

daira commented

2009-12-17 04:23:36 +00:00

Author

Looking at the contents of pages accessible from the web root, there are various other privacy issues besides the furls. Perhaps we need the option to have a locked-down server with only a minimal web root.

daira changed title from ~~Hiding the introducer and helper furls reported by a storage server on its web interface~~ to Hiding introducer and helper furls and other private info reported by a storage server on its web interface

2009-12-17 04:23:36 +00:00

imhavoc commented

2009-12-17 05:12:44 +00:00

Owner

Replying to davidsarah:

Looking at the contents of pages accessible from the web root, there are various other privacy issues besides the furls. Perhaps we need the option to have a locked-down server with only a minimal web root.

In my planned usage:

I want to be able to share a file in the grid, so being able to retrieve with a URI through a web-available node would be required. Ideally, though, the URI would only result in the file or directory that was shared being made available/exposed.

The full interface that is currently generated would be okay IF it was turned off by default for external interfaces (non-127.0.0.1), and each part could be turned on in the tahoe.cfg.

I do understand that the default interface is designed for localhost usage as a primary interface for some users.

Replying to [davidsarah](/tahoe-lafs/trac/issues/860#issuecomment-374846): > Looking at the contents of pages accessible from the web root, there are various other privacy issues besides the furls. Perhaps we need the option to have a locked-down server with only a minimal web root. In my planned usage: I want to be able to share a file in the grid, so being able to retrieve with a URI through a web-available node would be required. Ideally, though, the URI would only result in the file or directory that was shared being made available/exposed. The full interface that is currently generated would be okay IF it was turned off by default for external interfaces (non-127.0.0.1), and each part could be turned on in the tahoe.cfg. I do understand that the default interface is designed for localhost usage as a primary interface for some users.

warner commented

2009-12-18 00:52:32 +00:00

Concealing the Introducer FURL seems like a reasonable option. It requires two changes:

generate introducer FURLs with a real swissnum, not the emminently-guessable "introducer" name. This would change source:src/allmydata/introducer/server.py#L31 to call registerReference(introducerService, furlFile=os.path.join(basedir, "private", "introducer.furl")) instead of using "introducer" and the subsequent call to write_config.
a tahoe.cfg option that is interpreted by the webapi code (source:src/allmydata/web/root.py#L218, in data_introducer_furl) to return "hidden" instead of the actual FURL

(note that without the unguessable swissnum, anyone who can connect to your introducer's IP address can figure out the rest of the FURL. The tubid is public, the port number is easy to portscan, and "introducer" is easy to guess)

A filecap/dircap itself provides exactly the right authorities: read or read-write access to the given object. However you need a gateway to use it. The general assumption that I make is that people will use their own gateway (since you'll be revealing your caps to the gateway operator).

A URL-wrapped filecap/dircap (which includes the hostname+port of a webapi-implementing gateway node, via an <http://host/uri/> prefix) appears to provide additional authorities, such as everything else you can do with the webapi interface: create new directories, upload new files, and convert any other filecaps you happen to have into real file data. But these are probably ambient authorities anyways: if you suspect that I'm running a webapi gateway on testgrid.allmydata.com, it's trivial to portscan it for an HTTP server, and the webapi paths are all well-known (/uri, etc).

So protecting a webapi gateway from unauthorized use is another matter. It partly falls into the Accounting project (in that the gateway won't be able to consume storage space on the servers without some sort of authority, and the gateway won't have any of its own, so the HTTP client will have to provide it), but that's about protecting the storage server's disk space.

If the goal is to protect the gateway's CPU and bandwidth, then we need to create a new authority framework. It may be enough to have something very coarse-grained, like a secret prefix on the webapi URL (i.e. /nt5nscyox63/uri?t=mkdir instead of plain /uri?t=mkdir), and having the gateway listen only on HTTPS. In that system, giving someone a URL-wrapped filecap that references your gateway would give them full permission to do webapi things on your gateway, but other parties wouldn't be able to acquire that ability on their own.

We could make two separate prefixes, one which only accepts read/download operations, and another which accepts everything. This would let you give away an HTTP-ready URL for downloading a file through your gateway without also exposing the upload authority.
We could make this sort-of backwards compatible by defining the default prefix to be an empty string, and saying that the webapi server listens at $PREFIX/uri.

We've also talked about a tahoe.cfg switch which denies all upload operations on a gateway. Some folks have implemented this externally with an Apache frontend that blocks all PUT/POST/DELETE operations, only allowing GET through.

Concealing the Introducer FURL seems like a reasonable option. It requires two changes: * generate introducer FURLs with a real swissnum, not the emminently-guessable "introducer" name. This would change source:src/allmydata/introducer/server.py#L31 to call `registerReference(introducerService, furlFile=os.path.join(basedir, "private", "introducer.furl"))` instead of using "introducer" and the subsequent call to `write_config`. * a tahoe.cfg option that is interpreted by the webapi code (source:src/allmydata/web/root.py#L218, in `data_introducer_furl`) to return "hidden" instead of the actual FURL (note that without the unguessable swissnum, anyone who can connect to your introducer's IP address can figure out the rest of the FURL. The tubid is public, the port number is easy to portscan, and "introducer" is easy to guess) A filecap/dircap itself provides exactly the right authorities: read or read-write access to the given object. However you need a gateway to use it. The general assumption that I make is that people will use their own gateway (since you'll be revealing your caps to the gateway operator). A URL-wrapped filecap/dircap (which includes the hostname+port of a webapi-implementing gateway node, via an `<http://host/uri/>` prefix) appears to provide additional authorities, such as everything else you can do with the webapi interface: create new directories, upload new files, and convert any other filecaps you happen to have into real file data. But these are probably ambient authorities anyways: if you suspect that I'm running a webapi gateway on testgrid.allmydata.com, it's trivial to portscan it for an HTTP server, and the webapi paths are all well-known (/uri, etc). So protecting a webapi gateway from unauthorized use is another matter. It partly falls into the Accounting project (in that the gateway won't be able to consume storage space on the servers without some sort of authority, and the gateway won't have any of its own, so the HTTP client will have to provide it), but that's about protecting the storage server's disk space. If the goal is to protect the gateway's CPU and bandwidth, then we need to create a new authority framework. It may be enough to have something very coarse-grained, like a secret prefix on the webapi URL (i.e. `/nt5nscyox63/uri?t=mkdir` instead of plain `/uri?t=mkdir`), and having the gateway listen only on HTTPS. In that system, giving someone a URL-wrapped filecap that references your gateway would give them full permission to do webapi things on your gateway, but other parties wouldn't be able to acquire that ability on their own. We could make two separate prefixes, one which only accepts read/download operations, and another which accepts everything. This would let you give away an HTTP-ready URL for downloading a file through your gateway without also exposing the upload authority. We could make this sort-of backwards compatible by defining the default prefix to be an empty string, and saying that the webapi server listens at `$PREFIX/uri`. We've also talked about a tahoe.cfg switch which denies all upload operations on a gateway. Some folks have implemented this externally with an Apache frontend that blocks all PUT/POST/DELETE operations, only allowing GET through.

daira commented

2009-12-20 23:42:27 +00:00

Author

If you like this bug, you might also like #562 and #823.

daira modified the milestone from undecided to 1.7.0

2010-02-01 19:51:14 +00:00

zooko modified the milestone from 1.7.0 to eventually

2010-06-18 23:51:52 +00:00

daira commented

2011-01-06 08:21:45 +00:00

Author

If you like this bug, you might also like #587.

zooko commented

2011-05-19 16:29:10 +00:00

I just now became one of the people who wants this. I'd like to host two world-readable sites (my blog and the imminent Tahoe-LAFS Weekly News) on the volunteergrid without giving readers of those sites the ability to upload files to the volunteergrid. To do that we need this ticket to be fixed, and then also the ability to configure a gateway to be read-only so that it doesn't perform any uploads or updates of any file for any user. (This is one approach to #587.)

I just now became one of the people who wants this. I'd like to host two world-readable sites (my blog and the imminent *Tahoe-LAFS Weekly News*) on the volunteergrid without giving readers of those sites the ability to upload files to the volunteergrid. To do that we need this ticket to be fixed, and then also the ability to configure a gateway to be read-only so that it doesn't perform any uploads or updates of any file for any user. (This is one approach to #587.)

daira self-assigned this 2012-02-15 00:17:23 +00:00

daira modified the milestone from eventually to 1.10.0

2012-02-15 00:17:38 +00:00

daira commented

2012-05-23 02:38:58 +00:00

Author

As the example in the description shows, this applies to web interfaces on all node types, not just storage servers.

daira changed title from ~~Hiding introducer and helper furls and other private info reported by a storage server on its web interface~~ to Hiding introducer and helper furls and other private info reported by a node on its web interface

2012-05-23 02:38:58 +00:00

daira commented

2012-09-15 04:48:00 +00:00

Author

Replying to warner:

Concealing the Introducer FURL seems like a reasonable option. It requires two changes:

generate introducer FURLs with a real swissnum, not the emminently-guessable "introducer" name. This would change source:src/allmydata/introducer/server.py#L31 to call registerReference(introducerService, furlFile=os.path.join(basedir, "private", "introducer.furl")) instead of using "introducer" and the subsequent call to write_config.

This part is now #1802.

Replying to [warner](/tahoe-lafs/trac/issues/860#issuecomment-374849): > Concealing the Introducer FURL seems like a reasonable option. It requires two changes: > > * generate introducer FURLs with a real swissnum, not the emminently-guessable "introducer" name. This would change source:src/allmydata/introducer/server.py#L31 to call `registerReference(introducerService, furlFile=os.path.join(basedir, "private", "introducer.furl"))` instead of using "introducer" and the subsequent call to `write_config`. This part is now #1802.

daira commented

2013-03-21 23:13:44 +00:00

Author

The introducer and helper furl swissnums are censored as of changeset:9be1a940. I think that any remaining issues discussed here are covered by the following tickets:

#587 (Web nodes provide ambient upload authority)
#1447 (add read-only mode for gateways)
#1455 (WUI: ambiently accessible pages should framebust in order to prevent UI redressing attacks)
#1665 (Brainstorm webapi vulnerabilities between the operator and a user and between users.)
#1911 (Add authentication for WUI access)

If so, we can close this ticket.

The introducer and helper furl swissnums are censored as of changeset:9be1a940. I think that any remaining issues discussed here are covered by the following tickets: * #587 (Web nodes provide ambient upload authority) * #1447 (add read-only mode for gateways) * #1455 (WUI: ambiently accessible pages should framebust in order to prevent UI redressing attacks) * #1665 (Brainstorm webapi vulnerabilities between the operator and a user and between users.) * #1911 (Add authentication for WUI access) If so, we can close this ticket.

Rows
Columns