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-to...
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:
- User sends a message to bridges@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.