Two research groups studying onion services and running relays
Hi relay operators! I want to let you know about two upcoming research projects by academic research groups. The tl;dr is that they're running relays to do certain measurements, and so far as we can tell the proposed methodology is safe enough and worthwhile enough, but we invite you (and everybody) to evaluate it too. If you didn't already know about the Tor Research Safety Board, now you do: https://research.torproject.org/safetyboard.html https://blog.torproject.org/blog/tor-heart-pets-and-privacy-research-communi... The board's goal is to help researchers do better and safer research, that is, to *minimize privacy risks while fostering a better understanding of the Tor network and its users*. The board has been low-profile so far because it's just starting up, but now that we've handled six cases, I've put the details of some of these cases up on the safety board page: https://research.torproject.org/safetyboard.html#examples (Some of the cases are still anonymized because their paper is not yet finished or submitted or accepted.) In particular, check out cases 2017-02 and 2017-03. They have each put up a web page explaining their research project and why it's safe, and listing which relays are associated with the research. http://tor.ccs.neu.edu/ https://onionpop.github.io/ Let us know if you have any questions. --Roger
Roger Dingledine:
Hi relay operators!
Isn't that more relevant to HS operators than relay operators?
I want to let you know about two upcoming research projects by academic research groups. The tl;dr is that they're running relays to do certain measurements, and so far as we can tell the proposed methodology is safe enough and worthwhile enough, but we invite you (and everybody) to evaluate it too.
Do you review the design and implementation or design only?
In particular, check out cases 2017-02 and 2017-03. They have each put up a web page explaining their research project and why it's safe, and listing which relays are associated with the research. http://tor.ccs.neu.edu/
Trying to access this page via https times out. https would be appreciated. http://tor.ccs.neu.edu/safety-board.pdf wrote:
An adversary compromising $n-1$ HSDir servers cannot infer anything about counters or onion addresses.
If you design a system with these properties shouldn't the ISP also be part of your threat model? (especially with what we observed lately in FR) [...]
Again, we run relays controlled by three different entities over two continents with different jurisdictions, so avoid coerced disclosure of data.
Does the stated geo-diversity relate to the entities operating the measurement nodes or the location of the measurement nodes themselves? (I guess it is the former) If the list of fingerprints at http://tor.ccs.neu.edu/ is in fact complete and Maxmind has proper IP-to-AS data for these IPs than _all_ participating measurement servers are hosted using a _single_ hoster. http://tor.ccs.neu.edu/ wrote:
Experiment Status: OFF We are not running our relays and experiments now.
At least the relays seem to be running. Please publish the timeframe during which you will measure (like https://onionpop.github.io/ does) so HS operators who want to opt-out can shutdown their onions during that time if they wish to do so. -- https://mastodon.social/@nusenu https://twitter.com/nusenu_
On Thu, Aug 10, 2017 at 12:15:00AM +0000, nusenu wrote:
Isn't that more relevant to HS operators than relay operators?
No, not really. The relay operator community is the one with standards and consensuses about what counts as a well-behaving relay, and what kinds of "groups of relays that might look like a Sybil attack" are acceptable, and (related to the Sybils) how much of the network any one entity should control.
I want to let you know about two upcoming research projects by academic research groups. The tl;dr is that they're running relays to do certain measurements, and so far as we can tell the proposed methodology is safe enough and worthwhile enough, but we invite you (and everybody) to evaluate it too.
Do you review the design and implementation or design only?
Design only. There's an argument to be made for looking at the code too, but if I wanted to do that correctly, I would want to observe the deployment as well, and go check out the configuration of the machines, and interview the grad students who will be handling the data sets, and etc etc. I'm not sure where to draw the line, but assessing what they plan to do seems like a reasonable choice.
In particular, check out cases 2017-02 and 2017-03. They have each put up a web page explaining their research project and why it's safe, and listing which relays are associated with the research. http://tor.ccs.neu.edu/
Trying to access this page via https times out. https would be appreciated.
I noticed that too, but I guess not everybody is on the Let's Encrypt bandwagon yet. :)
http://tor.ccs.neu.edu/safety-board.pdf wrote:
An adversary compromising $n-1$ HSDir servers cannot infer anything about counters or onion addresses.
If you design a system with these properties shouldn't the ISP also be part of your threat model? (especially with what we observed lately in FR)
I think that's why they have three different locations (operated by three different research groups) for the relays. But oh hey, you're right, it looks like their implementation was simply to have three different research groups all run relays at the same ISP. :( Especially when they're all on VMs, it becomes a more straightforward exercise than I think they realize for the ISP to just go suck out all the memory of these systems.
Does the stated geo-diversity relate to the entities operating the measurement nodes or the location of the measurement nodes themselves? (I guess it is the former)
If the list of fingerprints at http://tor.ccs.neu.edu/ is in fact complete and Maxmind has proper IP-to-AS data for these IPs than _all_ participating measurement servers are hosted using a _single_ hoster.
Yes, it sure looks like this is the case. --Roger
participants (2)
-
nusenu -
Roger Dingledine