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

[Jacek Wielemborek]

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.

Cheers,
d33tah

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151210/06a0b2aa/attachment.sig>