Bitcoin-paid hidden meek relays?
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: 1. 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. Cheers, d33tah
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:
1. 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!
On Thu, 2015-12-10 at 13:22 +0200, George Kadianakis wrote:
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.
After we get Taler running then Taler becomes a payment option too : https://taler.net/ Although that does not solve the suckage around using money in general. Alternatively, one could build a Taler mint that uses an identifying document like a passport to open an account, but there after issues users a constant stream of anonymous tokens with which they can obtain new meek addresses. Ain't clear if that's really such a great idea either though as countries do not really run short of passports. Jeff
On 12/10/2015 08:35 PM, Jeff Burdges wrote:
After we get Taler running then Taler becomes a payment option too : https://taler.net/ Although that does not solve the suckage around using money in general.
Alternatively, one could build a Taler mint that uses an identifying document like a passport to open an account, but there after issues users a constant stream of anonymous tokens with which they can obtain new meek addresses. Ain't clear if that's really such a great idea either though as countries do not really run short of passports.
Jeff
Hi Jeff, By coincidence I picked up a brochure on Taler at the Post-Snowden Crypto event yesterday in Brussels, advertising it as "electronic payments *for a liberal society*" (emphasis in original). I don't know very much about Taler, but I'm curious about some text in the brochure from INRIA:
Taler is an electronic payment system that was built with the goal of supporting taxation. With Taler, the receiver of any form of payment is known, and the payment information comes attached with some data about what the payment was made for ... governments can use this data to tax businesses and individuals ... making tax evasion and black markets less viable.
For a user in a country where Tor is blocked, funding Tor bridges is, by definition, a black market in that country. Could you explain how you see this feature of Taler fitting with the threat model bridges are meant to address? Which governments should get detailed data on donations to bridges, and *to whom* is "the receiver of any form of payment" known? Should this data be accessible to goverments in illiberal societies (say, China) who block Tor, or just to governments in liberal societies (say, France, where Taler is developed), who would never block Tor? Thanks, Henry de Valence
Appears Isis has interesting work that addresses the bridge problem much more directly than anything in this thread. On Fri, 2015-12-11 at 15:52 +0100, Henry de Valence wrote:
Taler is an electronic payment system that was built with the goal of supporting taxation. With Taler, the receiver of any form of payment is known, and the payment information comes attached with some data about what the payment was made for ... governments can use this data to tax businesses and individuals ... making tax evasion and black markets less viable.
For a user in a country where Tor is blocked, funding Tor bridges is, by definition, a black market in that country.
Could you explain how you see this feature of Taler fitting with the threat model bridges are meant to address? Which governments should get detailed data on donations to bridges, and *to whom* is "the receiver of any form of payment" known?
Any anonymity system provides anonymity only within a particular anonymity set. A priori, a blind signing based system like Taler anonymizes the transactions between two anonymity sets, the customers and the merchants. Its mint always knows the total amount that each customer spends and the total income that each merchant receives, but not the specific transactions. In Taler, we ensure that a customer and a mint can collaborate to deanonymize the merchant side of a particular transaction, so the merchants are no longer an anonymity set. A merchant and mint cannot collaborate to deanonymize a customer side of a particular transaction though, so the customers remain an anonymity set. It follows that Taler cannot protect the identity of merchants from the country where the Taler mint is based. In the bridges case, a bridge user and the mint can collaborate to expose the operator of a particular bridge, which seems harmless, or even beneficial, and achievable via the CDN anyways. Jeff p.s. Aside from anonymity sets, one might worry about pseudo-anonymity of membership in the set of customers or merchants. In the bridge case, if say China hacked this meek mint, then they could learn whatever the mint knows about its customers, but not what bridge that customer paid for. A Taler mint funding bridge operators should ideally pass any user details it must retain through a data diode.
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:
1. 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.
participants (5)
-
David Fifield -
George Kadianakis -
Henry de Valence -
Jacek Wielemborek -
Jeff Burdges