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

[George Kadianakis]

Jacek Wielemborek <d33tah at gmail.com> writes:

> 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.
>
> What do you think about it? Hopefully I didn't mess it up in the
> fundamentals and this could actually help any little.
>

Hello there,

this seems like a promising avenue, but of course it has certain
community-building and engineering overheads.

It seems to me like a combination of two ideas:

- Flashproxy:

  Which is a bridge-less PT written by David et al. where the volunteer-run
  nodes are decentralized and trivial to setup.  It suffers from UX issues
  related to NAT penetration, but this will be fixed in the future when it's
  comboed with WebRTC.

- A better bridge distributor

  We've been discussing ways to improve BridgeDB for quite some time. The IP
  rate limiting that is currently in effect kind of sucks and everyone knows it.

  The next idea would be to rate limit based on a different scarce resource
  (e.g. Bitcoin, passport, etc.). All of them kind of suck for different
  reasons, but maybe some of them are fine for most threat models.

  I know that the BridgeDB crew has been working on a social distributor, where
  you get bridges if you have tokens and you can get tokens from your friends.
  The exact system is much more advanced and you can check it out here #7520.

I think help is needed in all these projects, so if you want to participate
maybe you can get in touch with the authors :)

Take care!