Grouping cloud relays running within same provider
Many people are running Tor relays on virtual servers "in the cloud", using VPS providers like Amazon EC2, Rackspace, Linode, etc. Most major VPS providers offer virtual servers in multiple geographical locations, but they are still controlled by one entity, which of course ultimately have total access to any storage (RAM and disk) of any customer VPS, easily compromising any crypto key material. I don't think it is necessarily that bad to trust VPS providers (and they often are a great way to get excellent bandwidth cheaply), but I feel it would be important to somehow make sure Tor users don't end up having circuits that all go through relays running on e.g. EC2. Same way you're supposed to group your own relays with MyFamily. Is there any way currently to do this, or are there already some safeguards in place?
Am 2014-04-18 21:31, schrieb mr.curtis@urssmail.org:
Is there any way currently to do this, or are there already some safeguards in place?
In its default configuration, Tor ensures that each relay in a circuit belongs to another /16 subnet (cf. Tor Path Specification [1], section "2.2. Path selection and constraints"). However, in the case of Amazon EC2, this constraint does not suffice as Amazon uses IP addresses from several different /16 subnets. Paul [1] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=path-spec.t...
On Fri, Apr 18, 2014 at 10:02:33PM +0200, Paul Staroch wrote:
Am 2014-04-18 21:31, schrieb mr.curtis@urssmail.org:
Is there any way currently to do this, or are there already some safeguards in place?
In its default configuration, Tor ensures that each relay in a circuit belongs to another /16 subnet (cf. Tor Path Specification [1], section "2.2. Path selection and constraints"). However, in the case of Amazon EC2, this constraint does not suffice as Amazon uses IP addresses from several different /16 subnets.
Note that this important but was not a guarantee even before the use of cloud relays. In my 2009 paper with Matt Edman "AS-Awareness in Tor Path Selection" we described the generation of 1500 paths using the Tor path selection algorithm "Of those 15,000 paths, 163 (or ≈ 1.1%) contained an entry and exit node that resided in the same AS despite having an IP address from different /16 subnets. Out of those 163 paths, all but one also had a distinct /8 network address." aloha, Paul
On Fri, Apr 18, 2014 at 4:21 PM, Paul Syverson <paul.syverson@nrl.navy.mil> wrote:
"Of those 15,000 paths, 163 (or ≈ 1.1%) contained an entry and exit node that resided in the same AS despite having an IP address from different /16 subnets. Out of those 163 paths, all but one also had a distinct /8 network address."
There are two questions new operators ask: - What provider allows Tor [exit] nodes so that I can place my new node there? (This is a very common question and leads directly to duplication.) - Where are there no relays right now so that I can try putting one there? (This question is so rarely asked that I cannot recall seeing it.) Even though 1.1% is small it (AS/cidr) does not cover some relevant crossfields such as legal jurisdiction, I still think a project to research current relays would be useful (cidr block, AS, [upstream] hosting provider, physical/govt location, relay operator and location, funding source, etc). Then new operators could query an xor report of fields with - input their prospective new relay - get a top ten list of where we are already too heavy, do not host there - use our data to suggest new placements, ie: we have no relays in these countries, in these AS by size, etc... It would make some sense to have onionooo plugin to carry this extended db, particular since hoster and some other fields would require human researched/maintained input.
On 22/04/14 20:42, grarpamp wrote:
On Fri, Apr 18, 2014 at 4:21 PM, Paul Syverson <paul.syverson@nrl.navy.mil> wrote:
"Of those 15,000 paths, 163 (or ≈ 1.1%) contained an entry and exit node that resided in the same AS despite having an IP address from different /16 subnets. Out of those 163 paths, all but one also had a distinct /8 network address."
There are two questions new operators ask: - What provider allows Tor [exit] nodes so that I can place my new node there? (This is a very common question and leads directly to duplication.) - Where are there no relays right now so that I can try putting one there? (This question is so rarely asked that I cannot recall seeing it.)
Even though 1.1% is small it (AS/cidr) does not cover some relevant crossfields such as legal jurisdiction, I still think a project to research current relays would be useful (cidr block, AS, [upstream] hosting provider, physical/govt location, relay operator and location, funding source, etc). Then new operators could query an xor report of fields with - input their prospective new relay - get a top ten list of where we are already too heavy, do not host there - use our data to suggest new placements, ie: we have no relays in these countries, in these AS by size, etc...
It would make some sense to have onionooo plugin to carry this extended db, particular since hoster and some other fields would require human researched/maintained input.
Coming late to this discussion, so I may be missing some context. First of all, did people following this thread see Compass? https://compass.torproject.org/ Note that we have a GSoC student this year, Christian, who's going to integrate Compass functionality into Globe. I'm sure he wouldn't mind input on that. https://globe.torproject.org/ Regarding the "extended db" that is mentioned above, if there's yet another data source that Onionoo should include, let's talk about that. I wouldn't want to be the human that does the research or maintain input, as you say. But if somebody else does that and if it's useful data, I can write the glue code to integrate those the new data into Onionoo. For reference, here's the relevant part of Onionoo's protocol specification: https://onionoo.torproject.org/#details All the best, Karsten
In its default configuration, Tor ensures that each relay in a circuit belongs to another /16 subnet (cf. Tor Path Specification [1], section "2.2. Path selection and constraints"). However, in the case of Amazon EC2, this constraint does not suffice as Amazon uses IP addresses from several different /16 subnets.
As does all of the bigger VPS providers that have connectivity in multiple countries. But the servers themselves are probably centrally managed by one company entity -- typically in the US. I would not be surprised if a single evil sysadmin could access any hypervisor machine having Tor relays running on them and steal their keys, without the relay operator noticing anything.
participants (5)
-
grarpamp -
Karsten Loesing -
mr.curtis＠urssmail.org -
Paul Staroch -
Paul Syverson