[tahoe-lafs-trac-stream] [tahoe-lafs] #1010: use only 127.0.0.1 as local address

[tahoe-lafs]

#1010: use only 127.0.0.1 as local address
-------------------------+-------------------------------------------------
     Reporter:  duck     |      Owner:  warner
         Type:           |     Status:  new
  enhancement            |  Milestone:  1.9.0
     Priority:  minor    |    Version:  1.6.1
    Component:  code-    |   Keywords:  privacy anonymity docs anti-
  network                |  censorship
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by zooko):

 * keywords:  privacy anonymity docs anti-censorship review-needed =>
     privacy anonymity docs anti-censorship


Comment:

 Okay, I've started reading the docs patch from
 attachment:cleanup-1010.dpatch:

 It helps to allay my confusion because it explicitly says "Note that this
 is not the same as omitting ``tub.location``.". However, it doesn't help
 all the way: what does it mean if you omit {{{tub.location}}}? (The
 answer, I believe is, that it discovers your local IP addresses and
 advertises them.) Does it mean anything if you say
 {{{tub.location=None}}}, or is that an error?

 I think there are four different use cases here, three of which are
 currently supported, and our docs should be more explicit about
 enumerating them.

 1. Discover your local IP addresses and announce them.
 2. Don't announce any routable IP address.
 3. Announce a configured IP address instead of the dynamically discovered
 one(s).
 4. [not supported yet] Announce a configured IP address in addition to the
 dynamically discovered one(s).

 Also: is there a valid distinction between

 * 2.a. Don't announce any routable IP address, but announce unrouteable
 (LAN-scoped) IP addresses. Then nodes from out on the Internet cannot open
 connection to you, but nodes on your LAN can. Also, people on your LAN can
 use this to confirm your identity as a certain Tahoe-LAFS node, even if
 nodes on the Internet can't. (Is this true? If you've for example,
 configured all of your outgoing connections to go through a Tor or I2P
 proxy, but you used this setting, then nodes within your LAN can open a
 direct TCP connection to you, do foolscap negotiation with you, and thus
 learn the mapping between your LAN-internal IP address and your foolscap
 node ID.)
 * 2.b. Don't announce any IP address except 127.0.0.1, meaning that nodes
 off your own host can't open TCP connections to you but people on your own
 host can. Again, does this mean you're vulnerable to an identity-revealing
 attack, even if you use Tor, if the attacker can open TCP connections from
 your own host? Is this a valid attack? It seems like it might be. What if
 there is some sort of TCP proxy running on your host so that, even though
 they can't execute arbitrary code on your host, they can open a TCP
 connection which looks to you as though it comes from your own host?
 * 2.c. Don't announce any IP address.

 Now this patch currently lets the user express option 2 by setting
 {{{tub.location=}}}, option 1 by setting no {{{tub.location}}}, and option
 3 by setting {{{tub.location=207.7.145.194}}}. I'm -1 on this design:

 * I find it confusing.
 * The docs here mix this issue with issue #1086, by saying that
 advertising an unrouteable IP puts you in "client only mode". In my
 opinion (and I recognize that gdt, at least, disagrees), whether your
 tahoe node initiates or accepts TCP connections should be independent of
 whether it acts a storage server, storage client, or both. (Or introducer
 or helper.)
 * I'm not sure if it is sufficiently safe to protect the identities (by
 which I mean IP-address-to-node-ID mappings) of Tor or I2P users. Perhaps
 we need to support option 2.c., above, instead.
 * I would prefer a design with an explicit {{{node.anonymous = True}}}, as
 we discussed above.
 * I would also prefer, I think, a design with option 2 being implemented
 by setting {{{tub.location=127.0.0.1}}}.
 We discussed one of those alternative designs above, and we said maybe we
 can changed out minds later, but this may be a mistake because
 * configuration file semantics are major backward-compatibility issues.

 Do we have a plan for how to provide backwards compatibility if we were to
 change to a different design in a future release? I guess we might need to
 have a phase where the {{{tahoe}}} node understood both old and new
 configuration formats, stopped with a fatal error if they were
 inconsistent, and emitted a warning if the old one existed at all. Then
 eventually we might go through another cycle like the one we just finished
 with #1385 where we stop with a fatal error if the old style is present.
 (By the way, #1385 turned out to be a lot more painful of a patch to
 integrate and debug than I had anticipated.)

 I'm willing to listen to counter-arguments, but at the moment I'm -1 on
 this design. I haven't finished reviewing the actual patches in
 attachment:cleanup-1010.dpatch, but I'm going to stop here and focus on
 #393 instead. I'm sorry I didn't think about the backward-compatibility
 issues earlier and that I didn't think about the specific configuration
 format earlier so I would realize I was uncomfortable with it before this
 late stage. (Also it is too bad I didn't think of the potential identity-
 revealing weakness earlier so we could have time to think it through
 before this late stage.)

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010#comment:29>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage