[tor-dev] Potential projects for SponsorR (Hidden Services)
Roger Dingledine
arma at mit.edu
Tue Oct 21 13:48:10 UTC 2014
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/IntegrationTesting/Proposal
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-encrypted-services.txt
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
More information about the tor-dev
mailing list