play nice with Tor onion services

[david415]

play nice with Tor onion services aka Tor hidden services.

Onion services provide at least three properties that ipfs users might find useful:

• end to end crypto transport
• enforce that the client must use Tor... to protect their identity
• protect the identity of storage node operators

This here is the "let's auto-detect ALL the user's IP addresses and announce them to the world" section:

https://github.com/ipfs/go-ipfs/blob/b1adeef85ce0558ca51754a01d6ebaac2ebeeccd/p2p/net/swarm/swarm_net.go#L116-L121

We'd like ipfs to have a anonymity mode configuration setting; if enabled this autodetection and announcement would be turned off. The ipfs onion peer operator would enter their "announcement address" into the ipfs configuration; in the case of Tor onion services this would include a onion address and port number.

I think it would also be great if ipfs allowed a heterogeneous configuration such that a node could announce itself as being available via ipv4/6 AND Tor. This of course would deanonymize the node operator but the onion service would still provide the other two properties I previously mentioned above. It is remarkable that Tor Project plans to provide "direct onion service" wherein the operator's identity is not protected be the client's is; this is great! This also means that "direct onion service" operators would utilize fewer resources on the Tor network.

What do core ipfs devs, core Tor devs and ipfs storage node operators think of this?

[jbenet]

@david415 thank you for starting this thread. it may be relevant eventually to move this discussion to: https://github.com/ipfs/notes/ and eventually https://github.com/ipfs/specs/ as it will be independent of go-ipfs impl. (but its fine to start discussion grounded in this implementation. just we should think implementation-independent in the long run)

including relevant statements from IRC:

17:12 <•jbenet> dawuud: im sure you can pipe all ipfs traffic through TOR. however i think you won't get the anonymity guarantees just by doing that. i think it will take a dedicated effort to make tor be a specific transport in ipfs and a special build (or configuration) to make sure ipfs doesn't break nonymity.
17:13 <•jbenet> dawuud: it's not that "ipfs wasn't designed with tor in mind", it's that "ipfs is transport agnostic" and the "current go-ipfs implementation of ipfs is not TOR-friendly yet"
17:14 <•jbenet> dawuud: also, for anonymity, an anonymity-friendly ipfs-routing system will be wanted. as a kademlia dht is not very friendly to anonymity.
17:15 <•jbenet> dawuud: so this needs work, but there's nothing about the ipfs design that prevents it being done.
17:17 <•jbenet> dawuud: (making very general protocols is a lot of work and we haven't gotten it all done yet :) -- the first use cases so far haven't needed anonymity, but intend to get there

(i'll clean this up + say more later.)

should add that: nobody should use stock go-ipfs as it is today and assume anonymity. we can work towards that but have important threat models to consider, code to audit, etc. this is very much doable -- nothing about ipfs design prevents anonymity -- but it is non-trivial work that needs to be done. (also note the crypto in go-ipfs has not been audited. (read security notes pls)).

[whyrusleeping]

are the Tor devs on github? can we ping them? @TheTorProject ?

[david415]

you can use the #tor-dev irc channel and the tor-dev mailing list to discuss tor dev related things (things like ipfs + tor). yes many (all?) of the tor devs use github. Yes... feel free to use their mailing lists to contact them and to illicit their opinions regarding this issue (i think it's relevant enough to discuss on their lists and irc channel).

[aagbsn]

Some Tor developers do use github, though an email to tor-dev@lists.torproject.org would reach more developers. You can view list archives at https://lists.torproject.org, e.g. the Direct Onion Services thread is:
https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html

[jbenet]

thank you @aagbsn

[isislovecruft]

Yes, some of us are on Github.

However, as @aagbsn mentioned, Github notifications aren't necessarily the fastest nor most reliable way to contact any of us. @david415's suggestion to use ircs://irc.oftc.net#tor-dev is the fastest; and tor-dev@lists.torproject.org is the most reliable.

I'd be glad to help provide feedback for a proposed design. :)

[BrendanBenshoof]

It might be worth only having TOR users connect to Bitswap and then only as client to the DHT (not peers). This would help with the latency issue, allow them to store + get files, but would not enable providing ipns. It would also be a step to supporting mobile devices, in-browser implementation or other high-churn high latency users.

As long as TOR is an additional transport for peers to announce (to ipv4 or ipv6) then that would work great. Having any nodes TOR-only transport could result in effectively partitioning the network. Kademlia is built on the assumption any node can connect to any other node on demand.

[whyrusleeping]

@BrendanBenshoof you bring up a good point about having client only dht nodes. For mobile, that is probably a really good idea, both for the mobile user with respect to their limited bandwidth, and for the network as slow peers arent healthy

[david415]

I started this thread to discuss supporting Tor Onion Services... it should be clear what the motivations for this are... but if not then feel free to ask questions. Yes Tor Onion Services have some additional latency... however in the future Tor Project will be working on Direct Onion Services which should have lower latency and different anonymity guarantees.

ipfs Tor clients should have their ID randomized.... obviously.

[whyrusleeping]

@david415 it might be good to lay out what guarantees you would want from ipfs-tor

[david415]

It should be perfectly clear that the high level goal is to enable future Snowden's to use this thing.

There should be an anonymity or tor mode wherein IPFS will not deanonymize the user. Further it should randomize the client ID each time it is started.

[BrendanBenshoof]

honestly, the best way to assume those guarantees is to maintain membership with bit-swap so you can provide files, but not act as a member of DHT. That way you could store and read records, without be actively tracked or hurting performance.

The use case would look like:

Lookup for a few random locations in the network, and build a "node-list" (not a peer list).
The you can randomly select from that node-list to initiate lookup for reads and writes of merkledag blocks. The primary security concern in Content-addressed network is censorship and deanonymization. this would act to minimize both. Each connection to a peer should use a different exit node if possible.

You would need to run a bitswap module to provide blocks. this would need to run as an onion service. The goal would be to provide a method for such nodes to offload providing onto other nodes. the less time the initial bit-swap service is up, the better. This feeds into the filecoin stuff.

The basic problem is that IPFS is meant to be a service run for a longer term. And one of the best things we can do to preserve anonymity is to minimize the user's vulnerable windows.

[david415]

We've moved the tracking of this important development effort to the following issue ticket:
ipfs/notes#37

[daviddias]

Awesome, thank you @david415, let's continue maintain the discussions on ipfs/notes#37 then. Closing this one for now :)

[autonome]

@BrendanBenshoof you bring up a good point about having client only dht nodes. For mobile, that is probably a really good idea, both for the mobile user with respect to their limited bandwidth, and for the network as slow peers arent healthy

Was there any further work on client-only nodes?

[Mikaela]

Would that be the same thing as --routing=dhtclient ?

• https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#client-mode-dht-routing