node-Tor is now open source in clear and modular

[Ayms]

FYI https://github.com/Ayms/node-Tor, javascript implementation of the Tor protocol in node and at browser side, in case it can be of some interest for IPFS one day (maybe missing in the description "IPFS is anonymous")

See the demo app

[Ayms]

To elaborate a bit more, a simple idea would be a duplex stream like ipfs.pipe(node-Tor) or .pipe(node-Tor), where the transport is TCP, WebSockets, WebRTC, inside nodes or browsers that can then act as nodes also to relay the protocol, node-Tor is not far from all of this in fact

[tobowers]

This is cool. Has anyone looked at making this a libp2p transport?

[Ayms]

The "idea" is now real and implemented, please see https://github.com/Ayms/node-Tor#forking-node-tor for the general principles and https://github.com/Ayms/node-Tor/tree/master/docs for the detailed documentation

So you can easily turn ipfs or any object to a Duplex object giving to it the evented pipe properties (see the simple typical setting example) and pipe it to the Tor protocol :

ipfs.pipe(node_Tor)

ipfs_dht.pipe(node_Tor)

Inside browsers or not, using a RendezVous point or peer to peer, both via onion circuits

Next steps might be to implement elliptic crypto and WebRTC

[bertrandfalguiere]

Just a heads-up that OpenBazaar has been implementing Tor as a transport for a long time: https://github.com/OpenBazaar/go-onion-transport

Another remark is that Tor used as a transport in an otherwise not modified/adapted IPFS implementation won't provide all the perks Tor normally provides (anonymity, etc.)
ipfs/notes#281 (comment)

There is another thread where @Stebalien writes that they won't implement Tor or other privacy-oriented overlay unless they change the security model from the ground up, which an enormous endeavour that will consequently not happen soon. But I can't find it.

[Ayms]

Thanks for the info but I feel like we are not talking about the same thing, and node-Tor is not new, it was implemented before openbazaar, ipfs, go even existed, and works inside browsers also which no other project does, it's now up to date with new methods and possible applications

Would be good to have the link to the @Stebalien thread to know why the Tor protocol cannot be implemented with ipfs

I read #281 and again feeling like we are mixing the Tor network behavior with the Tor protocol, a quick look to the openbazaar code seems to refer to onion addresses and hidden services, that's not the point at all of node-Tor to mimic the Tor network (even if compatible), and the use of onion addresses for a p2p network looks quite inept (node-Tor does not implement the hidden services but the RDV protocol instead based on hash advertising like a DHT)

Maybe a deeper look should be taken to node-Tor repo (and [Convergence]http://www.peersm.com/Convergence.pdf) principles), applying the same rules as the (centralized) Tor network for ipfs or bittorrent or any p2p network would be absurd, applying the Tor protocol is not, modified eventually if needed (example: Tor TLS with fake server names + the Tor protocol is somewhere absurd itself, Tor TLS +Tor protocol over DTLS for WebRTC is too, then TLS + IPFS over Tor TLS + Tor protocol would be the same)

And I don't see it as a "transport" protocol, the transport for me is more ws, webrtc, tcp/udp layer

Note: correcting the wrong link to the Convergence proposal

[Stebalien]

Issue: ipfs/kubo#6430

The core issue is this: Tor isn't enough for anonymity.

[Ayms]

Well, no in fact, unless there are some outstanding design issues with ipfs which I don't think can be the case

I have corrected the link above to the Convergence proposal (you should do the same for IPFS specs, it always returns to the github repos), it's probably of some interest to read it (even if I would modify some parts today)

Now looking at all the posts/links it's always the same story: copying the Tor network and hidden services, openbazaar stuff is just a few lines of codes, all of this probably leading at the end to the use the tentacular Tor project code

This is not what I am talking about, node-Tor implements the full Tor protocol and does not rely on anything else

I am not an expert for ipfs/ipns/iprs and the specs are still not very clear, anyway, the seeder can hide in the DHT using RDV points or peer to peer onion circuits, this is about the same in fact since both implement both functions, so it becomes difficult to know who is doing what (unlike the common belief seen in some posts stating that the more numerous you are the more you can hide, this does not work at all in fact, for example it's not very difficult to track a bittorrent user), and two hops are probably enough, the requester would hide the same way

It's indeed non trivial changes but at least node-Tor is there and easy to use to facilitate this

Ready to participate to this once you have time

See also Monitoring and blocking the bittorrent monitoring spies and private torrents

[bertrandfalguiere]

I'm not sure I get why you want it. But I'm no expert.
I think can Tor provide server anonymity, client anonymity, uncensorable services (servers), de facto proxying.
Maybe I missing something?

The 2 first will require that libp2p nodes never advertize non-onion addresses that would leak IPs, splitting the network between onion-nodes and everyting-else-nodes.
The uncensorable service can already be decentralised. The proxy thing can be achieved via relay.

I see what you don't want the Tor integration to be, but I don't see what you do want to use it for.

I really feel like I'm missing things here.

[Ayms]

I don't want anything, just proposing possible improvements for ipfs (or any protocol) anonymization

What you are missing I think is what everybody is (usually): mixing the Tor network design with the Tor protocol alone, we don't care about onion addresses, hidden services, even TLS with Tor, this can be achieved simply with a different design because the Tor network is (well) designed for what it has to do (ie centralized control and browsing) but for a p2p network this is different and same rules do not apply

[Ayms]

FYI the latest version (phase4) is now available on https://github.com/Ayms/node-Tor (phase4), it's still experimental but ready now to be integrated with ipfs or any protocol

The doc is here

And the browser demo is here: http://peersm.com/peersm4 (still some debugging stuff are slowing down the traffic and probably there are still some bugs in the demo interface, it is fast for p2p traffic, a bit slow when using a Tor exit node, apparently the Tor exit nodes are pausing the traffic, have to figure out why but anyway that's not the target of this project)

At least you know about it, again I would be ready when you are to participate to the design of anonymous ipfs using node-Tor if you like (there are indeed some specifics to design but would not see why/how everything should/could be reinvented, I have the name already: IPTS :-) ), will advertise protocol labs also @jbenet

Phase5 might come too including webRTC, elliptic crypto and v3 tor protocol features, maybe this can be combined with libp2p, thinking also to include it in browserify

The code is not fully ES6-like but this will come with time

[Ayms]

Phases 4 and 5 are on hold due to lack of funding (the repo was rolledback to phase 3 but phase 4 doc is here, but maybe we can optimize compared to what was foreseen (for example not reimplementing the WebRTC transport) knowing that ipfs/libp2p is not the only target or use case but could be used by others

After some discussions with Protocol Labs regarding some eventual grant/collaboration it was advised to post here to get the core devs opinions

So before this I took a (deep) look at the libp2p code, the specific pipe with iterables and muxer does not pipe natively to the node-Tor pipes methods but it's probably not difficult to pipe both, something like:

//upgradeOutbound
maConn.params_={OP:true,nb_hop:2,one_c:true}
piping.call(maConn);
maConn.conn._write=function(data) {
	maConn._stream_f.push(data); //sent to node_Tor
};
maConn._write_b=function(data) {
	maConn.conn.push(data); //received by node_Tor and pushed on maConn._stream_b
};
maConn.pipe(new node_Tor());

Just an example, this would work and intercept/redirect the traffic from/to the muxer, so is a kind of hack (looking a bit the other way around) since the ipfs socket/stream connects before upgrading the connection and is not used after (everything is redirected to node-Tor transport), don't focus on this, just to show that integrating node-Tor will not be thousands of lines of code, it-pipe could be implemented too

Currently I would see it in upgradeInbound and upgradeOutbound whether using the node-Tor transport (then node-Tor remains compatible with the Tor network nodes) and/or libp2p transport (probably better), it depends in fact of what orientations are taken if node-Tor is used:

• do we need Tor TLS? (my opinion: no, this thing using fake domains and self-signed certificates should be removed, but in that case we can't communicate any longer with Tor network nodes, anyway we can do both)
• do we need IPFS encryption? (Tor could be simply an option in the libp2p connEncryption options to replace secio when used, both can be combined also)
• do we need IPFS TLS? (probably not well aware of what is the plan here but saw some topics about it)

The proposed configuration is two hops between peers (and 3 if we go through Tor network nodes, that's not an "invention" of myself, others reached this conclusion when discussed on the lists), for each peer node-Tor creates 5 circuits with other peers, when a circuit is required it selects randomly one among the 5

Like libp2p connections there is the same notion of initiator or receiver for a Tor circuit and there is the notion of circuit extension also using the RDV protocol (and a Tor circuit is similar to a mplex muxer)

Each peer can serve directly the initiator or relay to another peer via the RDV protocol, especially if it can't serve what the peer is requesting, currently a simple hash is used to advertise to the RDV point what a peer has or do, I don't know exactly what IPFS does here, this is implemented but extending to more than one rdv point is not

So in addition to the anonymized circuit it probably becomes quickly difficult to know who is doing what and how many hops at the end are between the initiator and the real serving party

This is theoretical, I don't have any maths for this (why 5 circuits, why two hops, that's the same than for some specific settings for the Tor network or bittorrent --> because...) and think it should be experimented on the field, unless you have better solutions

I am sketching briefly here what could be the whole picture, elliptic crypto would be added to node-Tor too, for now I am not an expert at all with the whole ipfs ecosystem but many things intersect with my past convergence proposal and peersm specs (and the Tor protocol can be used for the different levels dht, transfer, etc)

Please let me know your thoughts

[momack2]

Hey @Ayms - IPFS is fully open source and you are more than welcome to build a version that integrates/builds on node-tor. I don’t think this thread does a good job clearly describing what you want to do and why, so I think the chances of upstreaming this change without clear demand are unlikely. However, if you build a version that DOES solve your problem cleanly that’d be very interesting so others can get a better sense of your vision and also make use of it if they share your constraints.

The power of open source is that you can optimize your use of something to meet your own needs. Feel free to grab the relevant pieces of IPFS to help unlock your vision and share back here with your learnings and outputs!

[Ayms]

@momack2 apparently we are not discussing the very same thing, I have zero problem, node-Tor is ready to be integrated with whatever protocol, I was asked by protocol labs to detail more what could be the design/integration for/with IPFS/libp2p and that's what I am doing, now you seem to be telling the contrary...

I still don't get why anonymity/privacy is not part of the general IPFS design, people are asking for it (there is a clear demand...) and the need will not evaporate, since node-Tor looks to be a good candidate to solve/help solving this I am proposing some solutions/collaboration but that's not at all "my" problem, that's IPFS' one

[momack2]

Ah - wasn’t clear to me from this thread whether you wanted node-tor integration for some purpose, or if you were just throwing out ideas. At the protocol level, there’s still a lot of work to ensure IPFS has default reader/writer privacy (there’s actually a full research open question on privacy preserving DHTs!), but it’s not on our short term roadmap. We don’t feel comfortable implementing “partial privacy” (ex without sufficient auditing and coverage over major use cases) since it could unintentionally lead people to use IPFS in insecure ways through false expectations of full anonymity. For folks optimizing for those use cases like Peergos, 3box, and Anytype - they’re doing privacy and encryption a layer above IPFS right now, where they can customize the experience and guarantees to their particular user needs.

Happy to keep this issue open for future tracking when we do our next roadmap prioritization effort - definitely agree reader/writer privacy is an important part of the long term vision!

[Ayms]

I don't think that I am proposing "partial privacy" but I am not saying that I have THE full solution, I was working on this before IPFS existed, maybe a look at the Convergence proposal has some interest (this is not a research study but was a proposal for a research study which gives the main ideas, extending Peersm concepts), many principles overlap with IPFS

Just proposing to work on this and possibly make a working prototype (I don't know what are the main directions of your research study but most likely it will use something like the Tor protocol, and I am not convinced that the theory can fix everything without experimentation on the field)

I understand that it's not your priority right now, the problem is that most likely it will not be mine later when I have moved to something else (you might not need me of course, now the project was rolled back to phase 3 and despite of all the efforts to reach this target I still doubt it is easy to use/integrate - if someone needs to restart from scratch later, then... it will be long and not trivial)

[hsanjuan]

Hey, thanks for bringing this to our attention. My takeaways here are:

• Node-tor is a JS library that could be used to adopt the Tor protocol for js-libp2p peers to communicate between themselves. Node-tor makes it easy to create channels/pipes that would provide anonymity like Tor does (but don't confuse this with using the Tor network or talking to current Tor Network nodes).
• Even if Node-tor is not a transport, the way to support this in js-libp2p would probably sit at the libp2p-transport level of things (UDP is a transport, but so is QUIC for us, which uses UDP below).
• In order to get full anonymity in IPFS, there is way more to consider than adopting Tor as a transport and the problem is of more magnitude that it seems at first.
• Integrating this into js-libp2p is not a priority right now so no work on this can be expected from core team. Anonymity is however a topic we are very interested in the long term.
• Anyone interested in making progress here right now is invited to work with Node-tor and try to integrate this themselves on js-libp2p. In fact, it might be relatively simple to slide in the pipes. Working PoC and exploration on how this can work with IPFS and what are the struggles might help/direct any future efforts.

I would suggest continuing this discussion at https://discuss.ipfs.io (this repository is not the best place). The forums probably get more eyes in the long term when people search for Tor. If libp2p abstractions do not fit well what needs to be done to integrate such "transport", https://github.com/libp2p/js-libp2p-interfaces seems a better place to propose and discuss specific upgrades to that.

Since I am in triaging mode, I think we can close this discussion here and we can always reference it from the forums if it continues over there. Thanks again everyone for taking the time to explain things!

[Ayms]

Your summary is correct, except that phase 4 (pipe methods) is not released (but the docs are), neither open source, because it was an anticipation/preparation for future funded work which did not happen and I will not support something abruptly stopped, it took me much more time than expected to implement phase 4, node-Tor is well designed but this one was not easy (see the doc: split the request object between the different layers), so I doubt people can build on phase 3

And it's not for ipfs only, whether it's a transport or not is only a question of wording, for libp2p I would see it where the connection gets encrypted, as a replacement option or with both

I have already posted on the ipfs discord