Bringing more onions into Polkadot

Ecosystem
1

Tor integration in the Dotsama ecosystem

Summary:

This is a post covering Tor(onion-routing) integration in the Dotsama ecosystem. A problem that is often faced is that several client libraries used to connect to rpc/ws nodes does not support socks5 proxies. In order to allow people to connect a .onion node, the connection must first be tunneled through a Tor proxy. An RFP was recently created in web3 foundations grant program in order to motivate developers to work on enabling socks5 support in the popular rust library JsonRpsee.

Problem statement:

As of writing this, Tor integration has not been a big focus area in the dotsama community. Because of lack of socks5 support in several client libraries, it makes it hard for end users to utilize connected

Proposed solution:

An RFP created to motivate developers to work on socks5 integration for JsonRpsee.

Background:

Tor is a anonymization project that has been active for several years. By utilizing a traffic obfuscation protocol to route data, it enables users to anonymize their internet traffic. Several blockchain projects leverage this technology to allow users to connect to nodes over tor, inputting the .onion address of the rpc provider.**

By providing a .onion address for a rpc/ws node, we can allow users to have more privacy by masking the origination of the request (the sender’s ip address).**

Gavin Wood mentioned onion-routing as an important future feature on Decoded 2023:
1600Ă—738 118 KB

In february 2023, a small public rpc provider was launched in order to provide .onion rpc endpoints for a handful of chains in the ecosystem.**Privhost was later listed on the awesome-substrate list.**

In order to connect to a .onion site, a user must pass it’s connection through a tor socks5 proxy in order to resolve the .onion domain and connect.**

Several ecosystem projects want to add support for connecting to .onion, but are blocked due to JsonRpsee not having support for sock5 proxy.**

Third party pr’s that are waiting for JsonRpsee to support socks5:**

On 4th of September of 2022 a pr was created **to start the process of adding socks5 support for JsonRpsee.Noone has had time to fix this issue and implement this feature, therefore this RFP has been drafted.

Case study:

Bitcoin Core (bitcoind) began supporting Tor (The Onion Router) for network communication in version 0.7.0, which was released on *April 19, 2012*. Tor support allows Bitcoin users to route their network traffic through the Tor network to enhance their privacy and anonymity when using Bitcoin.

Since that initial implementation, Tor support has been improved and integrated into subsequent Bitcoin Core releases, making it easier for users to run a Bitcoin node while maintaining a higher level of privacy. It’s important to note that using Tor with Bitcoin can help obfuscate the user’s IP address but may require some additional configuration and knowledge to use effectively.

I am a RPC provider and want to give my users more privacy, how can I provide .onion domains for my RPC nodes?

For RPC providers:

If you are running public ws nodes, you should consider offering .onion addresses as well, it’s normally no extra costs involved except for increased bandwidth(if your ISP charges you based on bandwidth load)

How to generate a .onion:

Install tor on your server, use an up to date version(for debian: https://support.torproject.org/apt/tor-deb-repo/).

Add the following in the` /etc/tor/torrc` configuration file:

HiddenServiceDir /var/lib/tor/wsnode/ # set directory

HiddenServicePort 9944 127.0.0.1:9944

Restart the tor daemon and view the hostname file in the “/var/lib/tor/wsnode” folder.

Note:

Rate limiting can not be done by blocking a certain ip after a certain amount of request, since all source ip’s will come from 127.0.0.1, in order to implement ddos protection, see the following guidelines put out by the Tor project:

I(flipchan) reached out to the Tor core developers and was told that “HiddenServiceExportCircuitID” is the silver bullet for enabling rate limiting.

Feel free to reach out directly to Privhost

Call for developers:

Are you a Rust developer looking for a new fun project? Then this might be for you!

RFP link:

https://grants.web3.foundation/docs/RFPs/jsonrpsee-proxy-support

1 Like
2

The Substrate client doesn’t necessary need to support all the features. An alternative will be use a reverse proxy that supports that. I didn’t research so I don’t know if there are existing tools available but good chance there is one.

Similarly, Substrate don’t support SSL, caching, rate limiting etc. You need something in front of it anyway for public production usage.

3

I added an ed235519 public key erased_pub to the design of Sassafras tickets, along with its corresponding ephemeral erased_secret, primarily to provide a .onion URL for collators with upcoming block production slots. It makes equivocation more slash-able too.

Ideally some Tor browser wallet should query the .onion URLs controlled by upcoming block producers, open a direct connection to a couple, and then post their tx without going through gossip. This enables anonymity protocols that leak something to the block producer.

We check crypto three times in polkadot, once on the 30ish validators who approval check the parablock, and twice on collators, once in the memepool and once in the block. If we used batch verification in blocks, then the mempool verification always costs more. A memepool verification only costs 50% more for schnorr, but memepool costs massively more for groth16 or other zk proofs.

In other words, Sassafras+Tor+batching avoids most of the CPU time of collators on parachains which check ZKPs produced by users (but not usually ZKP chains where collators make proofs). This makes is less wasteful to have more collators on a parachain.

I’m afraid SOCK5 support plus manual torrc does not really suffice though. You need wallet integration of course, but you also need the substrate node to spin up the hidden service for the erased_pub key. This requires either the tor control port, or else whatever better integration arti brings.

4

It’s important to understand that “privacy” has a very wide scope and is a difficult problem, and “adding onion support” isn’t a magic solution to that.

Adding Tor support would only hide the fact that you’re using Polkadot, which to me covers very little of what comes to mind when I think “privacy”.

The JSON-RPC server, then, is typically able to determine who is connected to them from the simple fact that the client will query the balance of the accounts of the user.

JSON-RPC servers have an incredible amount of de-anonymization power. This can be solved by running your own JSON-RPC server, but then you’re back to square one and you don’t need Tor support.

2 Likes
5

Yeah, if a user wants to enable filtering, they need to put up a reverse proxy between the connections, such as Nginx or Relayd.

Connections go Tor hiddenservice listeners > Nginx/Relayd reverseproxy > node client 9944

6

Tor is not a silver bullet, the goal of this post is to motivate someone to work on adding socks5 support in the client library JsonRpsee, so that developers and user can have the option to use a client handler that supports proxying connections and users can more easily choice to connect to a .onion ws node much easier

7

The reason why I’m not a fan of the idea is that if people connect through Tor, they would have a false impression that privacy is respected when they do so. In reality it really brings barely any, and so this would be misleading.

1 Like
8

An .onion serves two purposes: Any .onion improves site authentication for Tor browser users, even short 1-hop ones like facebook uses. A regular 3-hop .onion provides some anonymity for the node, but over time this get compromised.

Anonymity for users represent another matter. Yes. it rapidly becomes more complex: ZKPs for tx (zcash). Fetch chain state via PIR or messages (zcash never made it this far afaik). etc. All this gets hard, yes.

At the same time, there are simpler reasons like simply hiding your physical location from the node, but not hiding your identity. This is worth doing, especially for social media sites, even if it risks users’ overestimating their defenses.

Also, if you want to hide nodes locations, sassafras would only anonymize collators until they make their block, but one could extend it to anonymize them even during block production. Again worth doing, much better than long lived .onions.

Anyways, if someone wants to do this, then please do it from the tor control port, not just torrc. I guess SOCK5 would still be the first step, but libp2p likely provides that already.

1 Like
9

Totally understandable in a transparent ecosystem(where we have web3 big brothers such as Chainalysis etc…).

By providing .onion addresses for rpc nodes its a step towards more privacy.

I(flipchan) think it solves to problems:

  • 1: Masking physical location/ip address

  • 2: Preventing geo-blocking
    Avoiding country based geo-blocking by RPC providers.

Your transaction history and transaction privacy is another game.

10

Agree,

“Anonymity for users represent another matter. Yes. it rapidly becomes more complex: ZKPs for tx (zcash). Fetch chain state via PIR or messages (zcash never made it this far afaik). etc. All this gets hard, yes.” - This is a implementation parachain problem. CryptoNote(used by other protocols such as monero) is also a good example.

libp2p provides that, hopefully the ws client handler for JsonRpsee will have support for proxying connections through socks5.