2020 Summer Internship Project: Additional Tor Exit Nodes, Support Tor

[ChristopherA]

Last year Blockchain Commons helped Matt Corallo (@TheBlueMatt) to establish a new, long-term Tor exit node at NYC Mesh.

The was announced last August https://twitter.com/BlockchainComns/status/1161310976030867456:

Blockchain Commons was founded to support blockchain infrastructure, security & privacy. One project we are supporting & funding are @TheBlueMatt & @ChristopherA to stand an @torproject relay exit node with bandwidth provided by @as397444 via @nycmesh https://metrics.torproject.org/rs.html#details/644074F47257F9A906F9AA5C6B8926C1540A1DA8

We'd like to establish two more Tor exit nodes, one internet topologically near Asia, and then one as topologically far from both as possible (South Africa?). The Tor team may have advice on a better way to choose. Also relevant is access to Blockstream Satellite, mesh networks, etc.

There are multiple parts of this project (needs to be broken apart):

• Pick an intern lead
• Scope the work & milestones
• Budget the upfront and ongoing costs to Blockchain Commons for hosting additional nodes.
• Obtain an ASN for Blockchain Commons
• Work with @TheBlueMatt to return the two unused Swamp C's for use with Tor
• We have been offered the possibility of VM container space at various colo's by Bill Woodcock (@mwoodcock) of Packet Clearing House (@Packet-Clearing-House) to host the Tor exit. We should identify if this offer is still open and what their requirements are.
• Establish and document a standard VM or Docker container that can do Tor exit nodes. Goal: make it easier for others to replicate what we do. Host repo at Blockchain Commons or submit to @torproject.
• Setup ASN, Swamp C address space, routing and transit at colo.
• Turn on tor exit and test
• Long-term support checklist
• Repeat for 2nd solo

There will be interaction of this project with other projects this summer, including that Blockchain Commons hopes help document and support Tor better, hopes to host some other services via hidden .onion services, etc.

All of the above is open — this first message in this issue is to start the discussion.

cc/ @cprkrn @fakhrulKhir

-- Christopher Allen

[fakhrulKhir]

I am volunteering for this project.

Proposed Milestones

1. Get the paperwork finish and pull details from dependacies (@TheBlueMatt and @mwoodcock/.
2. Submit the application for ASN.
3. Get the scripts ready for Tor exit node deployment with testing.
4. Docker container template for future .onion hidden service.

Tasks

1. Communicate with @TheBlueMatt to get the relevant details about Swamp C.
2. See if the VM container offer from @mwoodcock are still available and the requirements for the available colo.
3. Get the details on getting ASN in Malaysia (APNIC for Asia Pacific), and how much does it cost.
4. Get the colo pricing for reference and do the budgetting if we are to host additional nodes.
5. Create a support checklist for maintenance references, and also for creating another node in the future.
6. Study on best practice to host a Tor exit node.

The cost for APNIC registration can be refer here and DO note that it is hard to get more than /23 unless with solid reasons.

Developments

• Create a standard Docker image for Tor exit nodes. Based on here
• Create automate scripts for Post-Install practices based on here
• Test the scripts and image to work on few Linux machines.
• Study the routing and networking for the colo hosting.
• Get the Tor project admin to check the scripts for improvements.
• Prepare metrics logging for monitoring the networks and resources usage.
• Prepare the Docker/scripts for .onion hidden services.

Questions

1. I am not sure if Blockchain Commons has previously register for ASN, and if we are to register at APNIC, I believe it takes documentations. Is it available? Or need to prepare them? If yes, might also put this as a task. ping @ChristopherA

Future

1. Prepare the .onion hidden service Docker container template for future services that might be hosted by Blockchain Commons.

[ChristopherA]

@fakhrulKhir This looks great, but really should be divided up into at least 3 key milestones, with rough dates, and any dependencies on others.

[ChristopherA]

Note that I gave @TheBlueMatt 3 swamp Cs /24s, called "swamp" as these /24s are routable individually. The first of which is used for our first Tor exit node. He agreed to return the other two when we needed them. So I don't think we'll need a new /23.

I'm unclear if we need a new ASN or if we can give my old ASN to Blockchain Commons. Rules have changed since I last did this.

-- Christopher Allen

[TheBlueMatt]

Depends on how you want to do it - if you are running it on PCH's infrastructure, probably you can just use their IPs if they're OK with it (I presume that would turn into many nodes, not just one, since they have many PoPs, and it would seem a waste to route a whole /24 to just one of their PoPs for just one node). If you are looking at Colo, I'd suggest doing your research, since many Colo sites aren't going to be cheap ($500-1k/mo) which may be a larger expense than makes sense long-term, and non-colo providers may not be ideal given a) they almost universally don't support using your own IPs, which means they are going to be unhappy with the abuse mails), and b) may not be ideal in the privacy-preserving domain that you'd ideally like to be running exit nodes.

[TheBlueMatt]

Also, if you're looking at hosting this in Malaysia, you should definitely look at the current legal status of Tor exit nodes in Malaysia before you set anything up.

[ChristopherA]

Thank you, @TheBlueMatt for your comments.

if you are running it on PCH's infrastructure, probably you can just use their IPs if they're OK with it

Yes, if we can get IP addresses for a Tor Exit from @Packet-Clearing-House via Bill Woodcock @mwoodcock that would be great. I'm not sure their level of commitment, so instead we may only be able to leverage their peering capabilities to make sure that the Tor Exit less expensively routes out.

If you are looking at Colo, I'd suggest doing your research

Yes, definitely. We are not just seeking multiple Tor exit nodes, but I want to establish some independent services, such as a .onion Esplora instance so we are not dependent on Blockstream, ideally (eventually) with its own Blockstream Satellite download capability. This requires some cooperation with a colo facility. Fortunately, @fakhrulKhir has some experience with multiple Asian cola centers.

Even before Esplora, Blockchain Commons want to be able to offer a public bitcoin price data feed, with independent software some signed checkpoints of price history that could optionally be installed a future version of Bitcoin Standup (see details in issue #6). We need this soon so that FullyNoded 2 can completely turn off of any non-.onion network features. Ideally we have this is US and two international locations.

In any case, the requires for the above are different than the requirements for a Tor Exit node, so they don't have to be locked together unless it is useful.

may not be ideal in the privacy-preserving domain that you'd ideally like to be running exit nodes.
…
Also, if you're looking at hosting this in Malaysia, you should definitely look at the current legal status of Tor exit nodes in Malaysia before you set anything up.

Yes, definitely a major issue. It was suggested that at least one colo in Malaysia was suitable for more wild west services, but who knows? This is one of our biggest weaknesses, not really knowing the Tor legal situations, but also wanting to support the common infrastructure of Tor, just as we hope that someday others will support Blockchain Commons as we become a more indispensable part of open infrastructure for Bitcoin.

@TheBlueMatt Seperately, if you have other ideas on how we might better serve other bitcoin network infrastructure needs, let us know!

-- Christopher Allen

[TheBlueMatt]

we may only be able to leverage their peering capabilities to make sure that the Tor Exit less expensively routes out.

I may be wrong, but I don't believe PCH is one global network, but instead hundreds of islands. Sure, hosting it at PCH in Amsterdam (or Frankfurt, but legal issues around Tor exits in .de probably prevent that) may have pretty good coverage from peering routes, but AMS-IX isn't perfect by itself. Still, they may get transit donated, so they may not care.

want to establish some independent services, such as a .onion Esplora instance so we are not dependent on Blockstream, ideally (eventually) with its own Blockstream Satellite download capability.

Depends on how YOLO you want to get with it, but may also make sense to investigate how well Tor can anycast (onionbalance used to be able to do it, but not sure what the state of things is with onion v3) and just try to set up a bunch for redundancy at cheaper sites instead of paying big bucks for a fancy place.

some signed checkpoints of price history

Of course unless you're doing this...if you're really serious about users of this, suddenly you care about not just any datacenter - most datacenters actually have really lax security, and those that are a bit more careful tend to cost more, not to mention that you'd want a cage, which is 10x the price. Of course maybe it doesn't make sense to care about all that stuff on day one, just things to think about.

It was suggested that at least one colo in Malaysia was suitable for more wild west services, but who knows?

"suitable for wild west" is probably not actually what you want - sure, maybe the datacenter/network provider doesn't care if you host some phishing or even malware C&C crap, but if INTERPOL comes knocking cause someone is using Tor for something Really Bad, you'd rather have robust legal protection than a network operator who doesn't care as long as it's not their problem.

[ChristopherA]

Depends on how YOLO you want to get with it, but may also make sense to investigate how well Tor can anycast (onionbalance used to be able to do it, but not sure what the state of things is with onion v3) and just try to set up a bunch for redundancy at cheaper sites instead of paying big bucks for a fancy place.

@TheBlueMatt — Wow, that tip was very helpful. And it does look onion balance has added v3 support: https://onionbalance.readthedocs.io/en/latest/v3/tutorial-v3.html#tutorial-v3

some signed checkpoints of price history

Of course unless you're doing this...if you're really serious about users of this, suddenly you care about not just any datacenter - most datacenters actually have really lax security, and those that are a bit more careful tend to cost more, not to mention that you'd want a cage, which is 10x the price. Of course maybe it doesn't make sense to care about all that stuff on day one, just things to think about.

You are correct, I've conflating the requirements of the two (or more) projects. Especially given your onion balance suggestion, we can try to have greater security in one place, and be less rigorous in the others. But in the long run I really want our users not to even depend on us for these services, instead give them a choice of many.

We are definitely need to do significantly more puzzling through the current price API risk models. Anything we do will be likely be better than the current state of the art where mobile wallets use a single source of current price information, typically the wallet vendor or a single exchange's API. Not only is this model vulnerable to DOS attacks, I suspect there are other tricks an attacker can do if they can make your remote wallet think the price has changed when it has not. Offering this services via Tor v3 also means we add a new attack surface that is less well known.

I don't necessarily want to replicate what Blockstream is doing with their current price data, but more desire to enable those who want to source it themselves for their own full node / remote wallet combos, that they can install an app alongside their full node that sources its own current data from APIs that user chooses. If they want to point their remote app to us, another reputable clone of our service, or directly to the API of their favorite exchange, or even test against multiple exchanges, it is up to them.

Our key requirement for this service is as much self-sovereignty for the full-node / remote wallet user as possible.

The historical data is also useful, but finding some way to distribute it safely is a different risk model than that for current price data.

Thank you for your comments!

-- Christopher Allen

[shannona]

I'm not sure of the final status of this project, but I'm closing it out as a Summer 2020 project.