Documenting best practices for P2P Sybil avoidance over Tor
Hi Applications Team! I would like to propose the following addendum to the SOCKS username section of the Tor-Friendly Applications Best Practices: "If your application needs to open a small number of connections (e.g. 10 long-lived connections) to a P2P network, and you want to prevent Sybil attacks, you should seriously consider using a unique SOCKS5 username per connection (e.g. by including a new randomly generated string in the username each time a connection is opened), which will minimize the chance of a malicious exit relay interfering with your view of the P2P network. For example, Bitcoin Core does this. On the other hand, if your application intends to open a very large number of connections, you should probably not do this, as it will put too much load on the Tor network. For example, Bitcoin DNS seeders should not do this while spidering P2P nodes." I think this is probably uncontroversial advice within the Tor community (I think the Tor devs are aware of Bitcoin Core's behavior and haven't asked the Bitcoin Core team to change it), but it is not necessarily obvious to application developers who may be unfamiliar with Tor, so I think it's worth documenting. Please let me know if this text is okay to add (or if there's anything that can be improved); I don't want to step on toes by adding this without consulting anyone. Cheers, -- -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy@veclabs.net is having technical issues at the moment.
This *seems* reasonable to me. tor daemon devs: we should probably explicitly call out best-practices w/ regards to circuit isolation when connecting to onion services as well. I assume there's no point security/privacy-wise in using multiple circuits when connecting to onion services (apart from enabling multiple concurrent streams/channels)? On 12/1/21 07:22, Jeremy Rand wrote:
Hi Applications Team!
I would like to propose the following addendum to the SOCKS username section of the Tor-Friendly Applications Best Practices:
"If your application needs to open a small number of connections (e.g. 10 long-lived connections) to a P2P network, and you want to prevent Sybil attacks, you should seriously consider using a unique SOCKS5 username per connection (e.g. by including a new randomly generated string in the username each time a connection is opened), which will minimize the chance of a malicious exit relay interfering with your view of the P2P network. For example, Bitcoin Core does this. On the other hand, if your application intends to open a very large number of connections, you should probably not do this, as it will put too much load on the Tor network. For example, Bitcoin DNS seeders should not do this while spidering P2P nodes."
I think this is probably uncontroversial advice within the Tor community (I think the Tor devs are aware of Bitcoin Core's behavior and haven't asked the Bitcoin Core team to change it), but it is not necessarily obvious to application developers who may be unfamiliar with Tor, so I think it's worth documenting. Please let me know if this text is okay to add (or if there's anything that can be improved); I don't want to step on toes by adding this without consulting anyone.
Cheers,
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
I expect there are benefits to using multiple circuits for onions if those circuits are used to isolate different identities. But yes, you're correct (I think) that preventing Sybil attacks is not one of those benefits. Suggesting the following clarified language: "If your application needs to open a small number of connections (e.g. 10 long-lived connections) to a P2P network, and you want to prevent Sybil attacks, you should seriously consider using a unique SOCKS5 username per non-onion connection (e.g. by including a new randomly generated string in the username each time a connection is opened), which will minimize the chance of a malicious exit relay interfering with your view of the P2P network. For example, Bitcoin Core does this. On the other hand, if your application intends to open a very large number of connections, you should probably not do this, as it will put too much load on the Tor network. For example, Bitcoin DNS seeders should not do this while spidering P2P nodes." We should also consider giving some advice on what to do when a large number of connections are expected (Isis documented the best practices for this on the Bitcoin Core issue tracker some years ago), but I don't think we should block the above addition on this. Incrementalism is good. :) Cheers, -Jeremy Richard Pospesel:
This *seems* reasonable to me.
tor daemon devs: we should probably explicitly call out best-practices w/ regards to circuit isolation when connecting to onion services as well. I assume there's no point security/privacy-wise in using multiple circuits when connecting to onion services (apart from enabling multiple concurrent streams/channels)?
On 12/1/21 07:22, Jeremy Rand wrote:
Hi Applications Team!
I would like to propose the following addendum to the SOCKS username section of the Tor-Friendly Applications Best Practices:
"If your application needs to open a small number of connections (e.g. 10 long-lived connections) to a P2P network, and you want to prevent Sybil attacks, you should seriously consider using a unique SOCKS5 username per connection (e.g. by including a new randomly generated string in the username each time a connection is opened), which will minimize the chance of a malicious exit relay interfering with your view of the P2P network. For example, Bitcoin Core does this. On the other hand, if your application intends to open a very large number of connections, you should probably not do this, as it will put too much load on the Tor network. For example, Bitcoin DNS seeders should not do this while spidering P2P nodes."
I think this is probably uncontroversial advice within the Tor community (I think the Tor devs are aware of Bitcoin Core's behavior and haven't asked the Bitcoin Core team to change it), but it is not necessarily obvious to application developers who may be unfamiliar with Tor, so I think it's worth documenting. Please let me know if this text is okay to add (or if there's anything that can be improved); I don't want to step on toes by adding this without consulting anyone.
Cheers,
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
_______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
-- -Jeremy Rand Lead Application Engineer at Namecoin Mobile email: jeremyrandmobile@airmail.cc Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C Send non-security-critical things to my Mobile with OpenPGP. Please don't send me unencrypted messages. My business email jeremy@veclabs.net is having technical issues at the moment.
participants (2)
-
Jeremy Rand -
Richard Pospesel