On Mon, Oct 20, 2014 at 02:37:49PM +0100, George Kadianakis wrote:
this is an attempt to collect tasks that should be done for SponsorR. You can find the SponsorR page here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR
Thanks for getting this going!
== Safe statistics collection ==
We've discussed this quite a bit over the past year and I think we all pretty much agree on which stats are safe to collect and which not.
I think we know some safe first-round things to collect. But I bet there's a lot more that's grey-area.
I think we all agree that collecting the number of HS circuits and traffic volume from RPs (#13192) is harmless [0] and useful information to have. We need to clean up Roger's patch to add that information in extra-info descriptors, and then do some visualisations. That would give us a good idea of how much HSes are used.
Sounds good.
OTOH, other statistics like "# of HS descriptors" are not that harmless and the upcoming HS redesign will block us from getting this information anyway.
How will the upcoming design block hsdirs from knowing how many descriptors they got? I agree that it'll be harder to know how many underlying hidden services they represent; but given a predictable publishing schedule and a number of descriptors you got, you should be able to derive an estimate for how many hidden services published to you.
The main goal of (that part of) the hsdesc redesign was to prevent hsdirs from learning how to visit the hidden service.
Unless we have a plan for the security property you describe?
For now, I think we should focus on #13192 for this project.
I'd like to branch out into a bunch of other stats too -- for example, how many intro points were established at my relay over the past 24 hours? How many rendezvous points? How many of those rendezvous points got used? What were the various usage stats of the intro points?
Basically, anything where we're pretty sure it can't be used for harm, but we can imagine finding numbers that surprise us, we should consider looking at, to see if we're surprised -- and we should collect the numbers over time, in case later they turn into something surprising.
The trickier examples, which we shouldn't deploy without more thought, would be things like "what is the median, 90th percentile, etc of bytes used on circuits where I'm the rendezvous point"? At the extreme, which is clearly in "don't do it" territory, we can imagine doing a website fingerprinting attack at the rendezvous point, to discover which hidden service it is and thus track popularity. See item #4 at the end of this mail for more next steps.
== Tor controller API improvements ==
To better refine this project, we should think about what we want to get out of it. Here are some outcomes:
a) A better control API allows us to perform better performance measurements for HSes.
All in all, this seems like a project worth doing right because it will be useful in the future. It can even act as an automated regression test.
I agree. I'd like us to get a really good answer in place here and then see what it tells us over time.
b) This might also be a good time to start working on automated integration tests for HSes.
It should be possible to spin up private Chutney networks and test that particular HSes are reachable. Or perform regression tests; for example, Roger recently suggested writing a regression test to make sure that clocks don't need to be synchronized to build HS circuits (#13494).
Yep. In general, I think there are many questions where we look at the code and wonder if it's behaving correctly. With a tool like Chutney, we should be able to instrument the whole network to *verify* that the code is behaving correctly. And with a bit more effort, we should be able to make that verification easier to do the second time.
Part of what I'm hoping we'll uncover with the Chutney tests is edge cases where most of the time it behaves as we expect, but every so often it goes really wrong. So we should think about what we want to capture from each relay in order to be able to track down the details of these anomalies.
And then we should figure out how to induce defects, like half of the hsdirs for the hidden service go down or drop the descriptor, and see if our algorithms still behave the way we expect.
Bonus points if it's pretty easy to reuse these steps on both Chutney and Shadow.
This work ties into https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorS/Integrat... so hopefully it will be a great area where SponsorR devs can collaborate with SponsorS devs, and where SponsorR devs can get up-to-speed on all our hidden service code.
c) Tor should better expose error messages of failed operations. For example, this could allow TBB to inform users whether they mistyped the onion address or the HS is actually down, and it would also let us do #13208. Proposal 229 and ticket #13212 are related to this. We should see whether the PT team is planning to implement proposal 229 and how we can synchronise.
Sounds great.
d) There are various projects that are using HSes these days (TorChat, Pond, GlobaLeaks, Ricochet, etc.). We should think whether we want to support these use cases and how we can make their life easier. For example, Fabio has been asking for a way to spin up HSes using the control port (#5976). What other features do people want from the control port?
Sounds great.
== Performance Improvements ==
This is the most juicy section. How can we make HS performance better? IIUC, we are mainly interested in client-side performance, but if a change makes both sides faster that's even better.
Remember that just as much as improving performance, we also want to reduce variance of performance.
So while many of the things you list are "I bet we could improve the design so in theory it should work better", we shouldn't skip over the "I wonder if we're actually doing the thing we think we are" questions, as well as the "ok yes we're doing it, but does it actually produce the results we think it does" questions.
It's pretty easy to justify refactoring of the code in the process of answering questions like these (which will hopefully pave the way for future design changes).
Some projects:
a) Looking at Karsten's #1944 results http://ec2-54-92-231-52.compute-1.amazonaws.com/ we see that fetching HS descriptors takes much more time than it should. I wonder why this is the case. Is there another ntohl bug there?
We should perform measurements and get a good understanding of what's going on in this step. Here are some tickets that Roger opened to do exactly that:
- #13208 What's the average number of hsdir fetches before we get the hsdesc?
- #13209 Write a hidden service hsdir health measurer
And here is a ticket with a potential issue:
- #13207 Is rend_cache_clean_v2_descs_as_dir cutoff crazy high?
Yep.
b) Improving the other parts of the circuit establishment process is also important:
- #8239 Hidden services should try harder to reuse their old intro points
- #3733 Tor should abandon rendezvous circuits that cause a client request to time out
- #13222 Clients accessing a hidden service can establish their rend point in parallel to fetching the hsdesc
Furthermore, an area of Tor that might give us better performance but we haven't really explored yet is preemptive circuits. #13239 is about building more internal circuits for HSes.
And here is a ticket suggesting more measurements:
- #13194 Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell
Yep.
c) Another important project in this area is parallelizing HS crypto. I haven't looked at what this would actually entail, but it will probably involve implementing the undone parts of proposal 220/224.
We should indeed ponder how useful we think this would be, but it will be hard to impress the funder with this one. That is, they won't object if we do this on our own time, but it isn't something I will easily be able to say "and look what else we did for you!" and get a good reaction.
d) This might be the time to implement Encrypted Services? Many people have been asking for this feature and this might be the right time to do it: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-enc...
Alas, this one also counts as "new design and development on hidden services", which isn't really in-scope. We can do it if we think it's important, but there are many things in that category.
e) Following the trail of #13207, we should look at all the magic numbers currently used by HSes, document them and see if they make sense. This includes the number of IPs (#8950), the number of HSDirs/replicas, the intro point expiration date, etc.
Yes!
f) On a more researchy tone, this might also be a good point to start poking at the HS scalability project since it will really affect HS performance.
We should look at Christopher Baines' ideas and write a Tor proposal out of them: https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html https://lists.torproject.org/pipermail/tor-dev/2014-May/006812.html Last time I looked, Christopher's ideas required implementing proposal225 and #8239.
Sounds great. I think #8902 falls squarely in this area too.
h) Back to the community again. There have recently appeared a few messaging protocols that are inherently using HSes to provide link layer confidentiality and anonymity [1]. Examples include Pond, Ricochet and TorChat.
Some of these applications are creating one or more HSes per user, with the assumption that HSes are something easy to make and there is no problem in having lots of them. People are wondering how well these applications scale and whether they are using the Tor network the right way. See John Brooks' mail for a small analysis: https://moderncrypto.org/mail-archive/messaging/2014/000434.html
It might be worth researching these use cases to see how well Tor supports them and how they can be supported better (or whether they are a bad idea entirely).
Yes. My guess is that it's lightweight to establish a circuit with each of your friends, and then when it goes away you try to reestablish it and if you fail then your friend is probably gone. And my guess is that it's heavyweight to try rendezvousing with each of your friends every 5 minutes to see if they're still there.
We should put up some guidelines for eco-friendly use of hidden services in this situation.
== Opt-in HS indexing service ==
For this project, we could make some sort of 'HS authority' which collects HS information (the HS descriptor?) from volunteering HSes. It's unclear who will run an HS authority; maybe we can work with ahmia so that they integrate it in their infrastructure?
The question of whether this has to be built-in is a fine one to explore. I bet we'd get more people doing it if it were just a torrc option that you can uncomment. But it also seems inherently less safe, since it might mean more publishings by your Tor than the human would do.
== Security / Miscellaneous ==
I also noticed that some tickets on trac were assigned to SponsorR but I couldn't fit them in the above categories. They are mainly security enhancements or code improvements. Here is a dump of the tickets:
Security:
- #13214 HS clients don't validate descriptor-id returned by HSDir
- #7803 Clients shouldn't send timestamps in INTRODUCE1 cells
- #8243 Getting the HSDir flag should require more effort
- #2715 Is rephist-calculated uptime the right metric for HSDir assignment?
Miscellaneous:
- #13223 Refactor rend_client_refetch_v2_renddesc()
- #13287 Investigate mysterious 24-hour lump in hsdir desc fetches
- #8902 Rumors that hidden services have trouble scaling to 100 concurrent connections
== Epilogue ==
What useful projects/tickets did I forget here?
1) We should identify and describe the great use cases of hidden services, especially the ones that are not of the form "I want to run a website that the man wants to shut down."
What sorts of hidden service examples are we missing from the world that we'd really like to see, and that would help everybody understand the value and flexibility of hidden services?
Along these lines would be fleshing out the "hidden service challenge" idea I've been kicking around, where as a follow-up to the EFF relay challenge, we challenge everybody to set up a novel hidden service. We would somehow need to make it so people didn't just stick their current website behind a hidden service -- or maybe that would be an excellent outcome?
2) Early results indicate that there are 25k-50k hidden services running currently; whereas Ahmia and friends know about maybe 1400 of them. So there is a lot of, shall we call it, dark matter in hidden service space. What are some safe ways we can improve our knowledge of this other 95% of the space?
3) One of the things special said was really good: a successful hidden service rendezvous is pretty lightweight, but an unsuccessful one really spends a lot of time and energy failing to fetch stuff before it fails. Can we make unsuccessful rendezvous connections less of a burden on the network, without interfering (much) with successful ones?
4) On the "whether it's safe to collect that measurement" front, it is in-scope to look at the science of how to decide whether it's safe. For example, the simplified view I've been taking is "if you collect a data set, and then you imagine somewhere out there is somebody else with some other arbitrary data set, does publishing your data set help that other person learn things about Tor users that you wish they couldn't learn?" If there's a way to formalize this question, or tie it into differential privacy, or otherwise move us beyond "think real hard and then if you don't see any problems do it", that would be great.
5) If you have a list of thousands of hidden service websites, and you want to fetch the pages from each of them, what parameters should you set on your fetcher to not take too much time, but also not trigger scalability problems in Tor that lead to wrong results? It seems that you'll want to do the fetches in a depth first way rather than breadth first, so you can make use of the established circuit? What other advice is useful here? Are there easy fixes we can make in Tor to allow more aggressive parameters to work? Will the tor2web patches help, and can we make better patches?
6) In general, anything that falls under the umbrella of "better understanding hidden services and their role in society" is fair game here. So far we've mostly emphasized the technical part of understanding them, which makes sense because we're mostly a technical organization. But we should think about whether there are steps we can take on the social side. And I think our funder will be sympathetic to "oh and we took these steps to improve the chance that hidden services will be used for good" too.
In other news, I plan at some point to write up a blog post explaining who the funder is and what exactly we're doing (and not doing!) for them. A few more things have to fall into place first though.
Thanks! --Roger