agowa
commented
4 years ago I'd like to add some thoughts about TOR, anonymity and onion transport integration for ipfs. If we take a look at tor, it basically is an overlay network that allows two nodes to connect to each other regardless of the underlying network conditions. Hidden services identify them selves using there public key.
What that means if we use tor (not focused on anonymity):
- We do not need to care about NAT traversal within IPFS
- We do not need to care about IPv4 or IPv6 only nodes.
- The anonymity part could be left to people needing anonymity like with other hidden services e.g. by running nginx or apache.
- We could use 0 or 1 hop routes in the default case allowing others to establish direct connections to us if possible, therefore anyone requiring ip anonymity could just increase this in the tor client config to require the connection to pass through other tor nodes first, but focusing on performance for anyone else.
- We could announce ipfs nodes as (or as a kind of) tor relays.
- We would add legitimate traffic to the tor network, to protect those who need to hide. Adding plausible deniability.
- And all other points you listed regarding anonymous mode could be solved by an operator running ipfs in a vm/container and tor in another and only allowing the tor vm/container to make outbound connections. ipfs would therefore be forced to use tor and all other features could just leak the internal ip of the ipfs vm. No further access would be possible. In fact that is the minimum setup for hidden services to stay anonymous even if someone could own your hidden service. And it also protects from stuff like the apache status page information disclosure bug.
- We do not need to protect ipfs nodes from being fingerprinted, as hidden services are already identifiable. Adding a recommendation of using ipfs without persistent configuration (e.g.
ipfs init) before each use for pure clients without any content could be added (as that is the only scenario that would be anonymous. - If one would like to go hard core, the tor client could be patched to allow outbound traffic of an hidden service to also originate from the hidden service address and therefore the connection could be the authentication. And that could be a nice feature for ipfs nodes that sync data between hidden services. Or just a simple way to add secure node to node authentication (like ipsec).
- Accessing ipfs/ipns resources could be fully anonymous depending on the needs of the client without the server operator needing to change anything.
Summary: I just want to say, that I see value in adding tor support early on as adding native support could free resources from other parts like nat/firewall traversal or ipv4/ipv6/mdns support, inter connectivity and focus resources on the important parts, like discovering and syncing content ;-)
ojej
balupton
luisarriojas
Stebalien
0xAnon101
RangerMauve
daslicht
willscott
pomid
marek22k
We've received many requests for anonymity support in go-ipfs. This issue tracks the issue and the related concerns.
First, there was a significant amount of work put into a tor transport. Unfortunately, reliable anonymity requires more than just TOR:
Unfortunately, this is a lot of work and we have no plans on working on this till after the IPFS 1.0 release. Getting this wrong could put users in serious danger so it's not something we'll even experiment with till we're ready.