[tor-dev] Bitcoin-paid hidden meek relays?

[David Fifield]

On Thu, Dec 10, 2015 at 12:09:36PM +0100, Jacek Wielemborek wrote:
> List,
> 
> I'm starting this thread in relation to the following discussion:
> 
> https://security.stackexchange.com/questions/107490/how-will-france-block-tor
> 
> I definitely don't have a perfect knowledge of Tor, so correct me if I'm
> wrong at any point. I heard that Tor entry nodes right now are
> distributed to users as IP addresses, which are scarce resources that
> could be blocked.
> 
> In order to make this more difficult, pluggable transports were
> introduced - those try to use other protocols to define communication
> with Tor network, lowering the cost of introducing new way to connect
> with it.
> 
> One that particularly caught my attention is Meek, which uses CDNs to
> evade censorship. CDNs share same IPs for many critical Internet
> serices, so blocking them is not an option and having them behind TLS
> makes it even more complicated.
> 
> The problem I noticed though is that the costs of Meek go up and if I
> read the reports from David Fifield (the maintainer of Meek), the
> bandwidth has to be limited to avoid abuse. This slows the transport
> down and I thought of another approach.
> 
> Instead of using a limited amount of Meek nodes, we could encourage
> users to run those on their own and distribute them in a way similar to
> regular Tor entry nodes. The catch would be that those nodes would
> require a small Bitcoin pre-payment that covers the cost of bandwidth
> used. The node would require the user to pass some proof of payment
> during the connection and not respond at all if there was no payment
> made. Here's an example way this could work:
> 
> 1. User sends a message to bridges at bridges.torproject.org with a request
> for a meek bridge and a GPG public key attached,
> 2. The bridge service replies with a Bitcoin address created just for
> the user,
> 3. As soon as the user sends any Bitcoins, it receives another e-mail
> with the hostname of the Meek relay and a token that one should use
> 
> Together with Amazon AWS, this could be an automated solution to the
> bandwidth and payment problem that would result in short-lived relays
> that are difficult to detect.

I like the idea of bridges that users pay for according to their use.
There are a lot of unanswered questions about how exactly the payments
and accounting work. It seems to me that this is a case where the
details are very important (I could be wrong).

I know of some research along these lines. "Proof-of-Work as Anonymous
Micropayment: Rewarding a Tor Relay" by Alex Biryukov and Ivan
Pustogarov (they worked out some of the protocol details):
	In this paper we propose a new micropayments scheme which can be
	used to reward Tor relay operators. Tor clients do not pay Tor
	relays with electronic cash directly but submit proof of work
	shares which the relays can resubmit to a crypto-currency mining
	pool. Relays credit users who submit shares with tickets that
	can later be used to purchase improved service.

One misunderstood thing about meek: it doesn't require a CDN to work.
You can fairly easily upload your own meek proxy (as a PHP or Python
script) to any HTTPS web host. The CDN and its collateral damage are
only required when you make the proxies widely known, as we do with
meek-google, meek-amazon, and meek-azure in Tor Browser. If you run your
own and do not share it widely, then you do not need a CDN.

For example, here is the PHP version:
	https://gitweb.torproject.org/pluggable-transports/meek.git/tree/php
Upload the index.php file to a web host service that supports HTTPS.
Then configure its URL as a bridge line in Tor Browser:
	meek 0.0.2.0:4 url=https://mysite.example.com/index.php

It's conceivable that we could even distribute such bridge lines in
BridgeDB. People could upload their PHP files and we could have a lot of
meek bridges. But BridgeDB is not currently set up for that. I don't
know exactly how it works, but BridgeDB assumes that the bridge is
running at the same place as a full Tor relay, which isn't the case for
a PHP forwarder like this. We also don't have a way for such PHP proxies
to automatically self-publish their URLs for others to use.