Jacek Wielemborek d33tah@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-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.
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!