Hi All,
I'm a graduate student at Princeton, and our research group has recently submitted a paper proposing a design for cloud based onion routing. The goal of our research is to securely perform onion routing on cloud based infrastructure (like Amazon EC2 and Rackspace) while allowing users to retain the same (or almost the same) privacy as when using Tor. We distribute trust across multiple cloud providers, and use Chaum's e-cash for payment and access control. Additionally, we hope that the elasticity of cloud infrastructure will make cloud based OR more censorship resistant than current systems.
This project is still in a relatively early stage, and we would love to get feedback from the Tor community. We would welcome any comments/questions/criticisms.
Our project's website is available at:
http://sns.cs.princeton.edu/projects/cor/
A direct link to our paper is here:
http://www.cs.princeton.edu/~najones/publications/cor-foci11.pdf
Our abstract:
Internet censorship and surveillance have made anonymity tools increasingly critical for free and open Internet access. Tor, and its associated ecosystem of vol- unteer traffic relays, provides one of the most secure and widely-available means for achieving Internet anonymity today. Unfortunately, Tor has limitations, including poor performance, inadequate capacity, and a susceptibility to wholesale blocking. Rather than utilizing a large number of volunteers (as Tor does), we propose mov- ing onion-routing services to the “cloud” to leverage the large capacities, robust connectivity, and economies of scale inherent to commercial datacenters. This paper de- scribes Cloud-based Onion Routing (COR), which builds onion-routed tunnels over multiple anonymity service providers and through multiple cloud hosting providers, dividing trust while forcing censors to incur large collat- eral damage. We discuss the new security policies and mechanisms needed for such a provider-based ecosys- tem, and present some preliminary benchmarks. At to- day’s prices, a user could gain fast, anonymous network access through COR for only pennies per day.
Thanks!
Nick Jones
I have a few questions
Q1: Regarding network bootstrap protocol: Consider the scenario where a censor mines the boostrap node list and blocks these nodes. Do you implement any mechanisms to prevent a censor from obtaining the entire set of bootstrap nodes? Similarly, aren't public directory servers also vulnerable to censorship?
Q2: Regarding token redemption: Does an ASP relay contact the ASP token bank through COR? Could the token verification history be used to reveal which paths were constructed?
--Aaron
On Wed, Jul 13, 2011 at 11:47 AM, Nick Jones najones@cs.princeton.edu wrote:
Hi All,
I'm a graduate student at Princeton, and our research group has recently submitted a paper proposing a design for cloud based onion routing. The goal of our research is to securely perform onion routing on cloud based infrastructure (like Amazon EC2 and Rackspace) while allowing users to retain the same (or almost the same) privacy as when using Tor. We distribute trust across multiple cloud providers, and use Chaum's e-cash for payment and access control. Additionally, we hope that the elasticity of cloud infrastructure will make cloud based OR more censorship resistant than current systems.
This project is still in a relatively early stage, and we would love to get feedback from the Tor community. We would welcome any comments/questions/criticisms.
Our project's website is available at:
http://sns.cs.princeton.edu/projects/cor/
A direct link to our paper is here:
http://www.cs.princeton.edu/~najones/publications/cor-foci11.pdf
Our abstract:
Internet censorship and surveillance have made anonymity tools increasingly critical for free and open Internet access. Tor, and its associated ecosystem of vol- unteer traffic relays, provides one of the most secure and widely-available means for achieving Internet anonymity today. Unfortunately, Tor has limitations, including poor performance, inadequate capacity, and a susceptibility to wholesale blocking. Rather than utilizing a large number of volunteers (as Tor does), we propose mov- ing onion-routing services to the “cloud” to leverage the large capacities, robust connectivity, and economies of scale inherent to commercial datacenters. This paper de- scribes Cloud-based Onion Routing (COR), which builds onion-routed tunnels over multiple anonymity service providers and through multiple cloud hosting providers, dividing trust while forcing censors to incur large collat- eral damage. We discuss the new security policies and mechanisms needed for such a provider-based ecosys- tem, and present some preliminary benchmarks. At to- day’s prices, a user could gain fast, anonymous network access through COR for only pennies per day.
Thanks!
Nick Jones _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Wednesday, July 13, 2011 at 4:58 PM, Aaron wrote:
I have a few questions
Q1: Regarding network bootstrap protocol: Consider the scenario where a censor mines the boostrap node list and blocks these nodes. Do you implement any mechanisms to prevent a censor from obtaining the entire set of bootstrap nodes? Similarly, aren't public directory servers also vulnerable to censorship?
Currently, we don't have any major protection from enumerating the list of bootstrapping nodes. It is definitely a problem we are aware of, and we're thinking about possible ways to protect them. In our design, we only give out one bootstrapping node at a time, with the hope that this makes enumerating them somewhat more difficult. Additionally, if we can detect that a bootstrapping node has been blocked, we can use the elasticity of cloud hosting to move it to a new IP or a new cloud. Admittedly, this may devolve into a cat and mouse game of moving the bootstrapping nodes around.
Similarly, since you learn about the bootstrapping nodes through the directories, the directories have many of the same problems and solutions. If the directories stay at a static IP/DNS name, then they will be blocked quickly. However, if the user still has a cached valid directory from the last time he was connected to COR, he could build a circuit and then retrieve an updated directory, assuming at least some of the nodes from the last directory retrieval were still active. We can move the directories around within the cloud, but then you need a "directory of directories", and that gets messy.
Admittedly, our system doesn't fundamentally solve the bootstrapping problem (of new users gaining access), but we hope that it makes it more difficult for existing users to be blocked.
Q2: Regarding token redemption: Does an ASP relay contact the ASP token bank through COR? Could the token verification history be used to reveal which paths were constructed?
The ASP relay contacts the ASP token bank directly. If multiple malicious ASPs colluded, they might use token redemption timing analysis to figure out the circuit's path. However, this isn't really any different than normal timing attacks. The tokens themselves can't be traced back to the user in any way. You need to use multiple ASPs to be protected, much like you need to use relays in Tor from multiple ISPs.
--Aaron
On Wed, Jul 13, 2011 at 11:47 AM, Nick Jones <najones@cs.princeton.edu (mailto:najones@cs.princeton.edu)> wrote:
Hi All,
I'm a graduate student at Princeton, and our research group has recently submitted a paper proposing a design for cloud based onion routing. The goal of our research is to securely perform onion routing on cloud based infrastructure (like Amazon EC2 and Rackspace) while allowing users to retain the same (or almost the same) privacy as when using Tor. We distribute trust across multiple cloud providers, and use Chaum's e-cash for payment and access control. Additionally, we hope that the elasticity of cloud infrastructure will make cloud based OR more censorship resistant than current systems.
This project is still in a relatively early stage, and we would love to get feedback from the Tor community. We would welcome any comments/questions/criticisms.
Our project's website is available at:
http://sns.cs.princeton.edu/projects/cor/
A direct link to our paper is here:
http://www.cs.princeton.edu/~najones/publications/cor-foci11.pdf
Our abstract:
Internet censorship and surveillance have made anonymity tools increasingly critical for free and open Internet access. Tor, and its associated ecosystem of vol- unteer traffic relays, provides one of the most secure and widely-available means for achieving Internet anonymity today. Unfortunately, Tor has limitations, including poor performance, inadequate capacity, and a susceptibility to wholesale blocking. Rather than utilizing a large number of volunteers (as Tor does), we propose mov- ing onion-routing services to the “cloud” to leverage the large capacities, robust connectivity, and economies of scale inherent to commercial datacenters. This paper de- scribes Cloud-based Onion Routing (COR), which builds onion-routed tunnels over multiple anonymity service providers and through multiple cloud hosting providers, dividing trust while forcing censors to incur large collat- eral damage. We discuss the new security policies and mechanisms needed for such a provider-based ecosys- tem, and present some preliminary benchmarks. At to- day’s prices, a user could gain fast, anonymous network access through COR for only pennies per day.
Thanks!
Nick Jones _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org (mailto:tor-dev@lists.torproject.org) https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org (mailto:tor-dev@lists.torproject.org) https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hopefully that answers your questions. If anything isn't clear, please let me know. We appreciate and welcome the feedback.
Thanks,
Nick Jones
Cool stuff. I like how the system can be automated and self-funding.
With regards to bootstrapping, giving out one node at a time is not a useful defense because requests can be parallelized. [1] Moving nodes is similarly useless because the attacker can continually map the network using free parallelized requests. Therefore, requesting a node address needs to cost something. [2] Since you already have tokens, you can just make it cost a token to request a node address.
To solve the initial introduction problem, you need to include fresh node addresses with the distribution of the executable. You could in fact dispense with the directory servers, which add no defense, and include fresh node addresses with each executable upon download. For instance, with BitTorrent we had a neat trick where we would encode the URL to a torrent file at the end of the uTorrent executable (dynamically for each user when they downloaded it from the web server) and the program new how to look for and extract this URL upon startup. If present, uTorrent would automatically start downloading this torrent. You could use a similar technique here. Much as above, getting fresh peers, in this case by downloading the executable, should cost something so that it can't be parallelized for free.
An alternative to paying per node address is to pay to establish an identity and then use a DHT to map node addresses to identities so that you have a way to obtain new addresses as they change due to churn, but mapping the whole network requires multiple identities and so once again incurs a linear cost. [2]
Best of luck with your project!
[1] Sybil attack http://www.cs.rice.edu/Conferences/IPTPS02/101.pdf [2] Arcadia http://blanu.net/Arcadia.pdf
On Wed, Jul 13, 2011 at 6:32 PM, Nick Jones najones@cs.princeton.eduwrote:
On Wednesday, July 13, 2011 at 4:58 PM, Aaron wrote:
I have a few questions
Q1: Regarding network bootstrap protocol: Consider the scenario where a censor mines the boostrap node list and blocks these nodes. Do you implement any mechanisms to prevent a censor from obtaining the entire set of bootstrap nodes? Similarly, aren't public directory servers also vulnerable to censorship?
Currently, we don't have any major protection from enumerating the list of bootstrapping nodes. It is definitely a problem we are aware of, and we're thinking about possible ways to protect them. In our design, we only give out one bootstrapping node at a time, with the hope that this makes enumerating them somewhat more difficult. Additionally, if we can detect that a bootstrapping node has been blocked, we can use the elasticity of cloud hosting to move it to a new IP or a new cloud. Admittedly, this may devolve into a cat and mouse game of moving the bootstrapping nodes around.
Similarly, since you learn about the bootstrapping nodes through the directories, the directories have many of the same problems and solutions. If the directories stay at a static IP/DNS name, then they will be blocked quickly. However, if the user still has a cached valid directory from the last time he was connected to COR, he could build a circuit and then retrieve an updated directory, assuming at least some of the nodes from the last directory retrieval were still active. We can move the directories around within the cloud, but then you need a "directory of directories", and that gets messy.
Admittedly, our system doesn't fundamentally solve the bootstrapping problem (of new users gaining access), but we hope that it makes it more difficult for existing users to be blocked.
On Wednesday, July 13, 2011 at 8:02 PM, Brandon Wiley wrote:
Cool stuff. I like how the system can be automated and self-funding.
With regards to bootstrapping, giving out one node at a time is not a useful defense because requests can be parallelized. [1] Moving nodes is similarly useless because the attacker can continually map the network using free parallelized requests. Therefore, requesting a node address needs to cost something. [2] Since you already have tokens, you can just make it cost a token to request a node address.
I agree with most of your points, but if we make users redeem a token to in order to access bootstrapping, they have to already have tokens, which is another bootstrapping problem in itself. Also, a determined adversary could just purchase enough tokens to perform the same attacks. Admittedly, we might make a lot of money from the censors in the process, which would be cool.
To solve the initial introduction problem, you need to include fresh node addresses with the distribution of the executable. You could in fact dispense with the directory servers, which add no defense, and include fresh node addresses with each executable upon download. For instance, with BitTorrent we had a neat trick where we would encode the URL to a torrent file at the end of the uTorrent executable (dynamically for each user when they downloaded it from the web server) and the program new how to look for and extract this URL upon startup. If present, uTorrent would automatically start downloading this torrent. You could use a similar technique here. Much as above, getting fresh peers, in this case by downloading the executable, should cost something so that it can't be parallelized for free.
This is a cool idea. Definitely will investigate this more.
An alternative to paying per node address is to pay to establish an identity and then use a DHT to map node addresses to identities so that you have a way to obtain new addresses as they change due to churn, but mapping the whole network requires multiple identities and so once again incurs a linear cost. [2]
Best of luck with your project!
[1] Sybil attack (http://www.cs.rice.edu/Conferences/IPTPS02/101.pdf) [2] Arcadia (http://blanu.net/Arcadia.pdf)
Thanks for your comments. Very much appreciated!
-Nick Jones
On Wed, Jul 13, 2011 at 6:32 PM, Nick Jones <najones@cs.princeton.edu (mailto:najones@cs.princeton.edu)> wrote:
On Wednesday, July 13, 2011 at 4:58 PM, Aaron wrote:
I have a few questions
Q1: Regarding network bootstrap protocol: Consider the scenario where a censor mines the boostrap node list and blocks these nodes. Do you implement any mechanisms to prevent a censor from obtaining the entire set of bootstrap nodes? Similarly, aren't public directory servers also vulnerable to censorship?
Currently, we don't have any major protection from enumerating the list of bootstrapping nodes. It is definitely a problem we are aware of, and we're thinking about possible ways to protect them. In our design, we only give out one bootstrapping node at a time, with the hope that this makes enumerating them somewhat more difficult. Additionally, if we can detect that a bootstrapping node has been blocked, we can use the elasticity of cloud hosting to move it to a new IP or a new cloud. Admittedly, this may devolve into a cat and mouse game of moving the bootstrapping nodes around.
Similarly, since you learn about the bootstrapping nodes through the directories, the directories have many of the same problems and solutions. If the directories stay at a static IP/DNS name, then they will be blocked quickly. However, if the user still has a cached valid directory from the last time he was connected to COR, he could build a circuit and then retrieve an updated directory, assuming at least some of the nodes from the last directory retrieval were still active. We can move the directories around within the cloud, but then you need a "directory of directories", and that gets messy.
Admittedly, our system doesn't fundamentally solve the bootstrapping problem (of new users gaining access), but we hope that it makes it more difficult for existing users to be blocked.
tor-dev mailing list tor-dev@lists.torproject.org (mailto:tor-dev@lists.torproject.org) https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Fri, Jul 15, 2011 at 3:16 PM, Nick Jones najones@cs.princeton.eduwrote:
On Wednesday, July 13, 2011 at 8:02 PM, Brandon Wiley wrote:
Cool stuff. I like how the system can be automated and self-funding.
With regards to bootstrapping, giving out one node at a time is not a
useful defense because requests can be parallelized. [1] Moving nodes is similarly useless because the attacker can continually map the network using free parallelized requests. Therefore, requesting a node address needs to cost something. [2] Since you already have tokens, you can just make it cost a token to request a node address.
I agree with most of your points, but if we make users redeem a token to in order to access bootstrapping, they have to already have tokens, which is another bootstrapping problem in itself. Also, a determined adversary could just purchase enough tokens to perform the same attacks. Admittedly, we might make a lot of money from the censors in the process, which would be cool.
You have hit upon the two main challenges of censorship-resistant bootstrapping. Most solutions add a layer which is itself vulnerable to the same attacks and is therefore not helpful. Through recursive analysis you eventually come to the initial introduction problem, which you must solve anyway because the users must obtain the software in the first place. You therefore need an out-of-band (from the perspective of the censor) introduction channel. As long as you have such a channel, you might as well use it to do the rest of the communication necessary for bootstrapping. See for example my Dust http://blanu.net/Dust.pdf paper on using out-of-band channels to establish secure communication over censored channels.
The second challenge is that, given a method of introduction, the attacker can map and block the entire network easily. Therefore introductions must have a non-parallelizable cost. However, if your attacker has enough resources to pay the cost then you're out of luck. So there is an ongoing search for a resource which is sufficiently plentiful for normal users to spend for the purpose of normal introduction, but which is difficult to obtain in large amounts. Alternatives to money have been suggested such as computing power, human labor or attention, storage space, etc.. Ultimately, though, all resources are convertible to and from money. I know of no ideal solutions to this problem, but the best I've seen limit the damage the attacker can do by requiring continual expenditure of resources in order to maintain an ongoing attack.
-
Aaron -
Brandon Wiley -
Nick Jones