[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Should popularity-hiding be a security property of hidden services?
Hello,
Tor hidden services are meant to primarily provide server anonymity
but they also provide various other properties. For example, their
addresses are self-authenticated and their connections punch NAT. This
post is about another property, which is that Tor does not reveal the
popularity of a hidden service by default. That is, you can't easily
get the user count of a specific hidden service.
This is not that surprising to hidden service operators, since that's
also how the normal Internet works. In the normal Internet, someone
cannot learn the user count of an IP or website, except if they are
the operator or they control DNS or the site publishes analytics.
Over the past years, people have suggested various features that would
provide us with interesting information and optimizations but would
have the side effect of revealing the user count of hidden services
(or only of popular hidden services) to the public.
Some examples of such popularity-leaking features:
- Hidden Services dynamically set their number of Introduction Points
depending on their popularity. Basically, they self evaluate their
popularity, and use a formula to decide the number of Introduction
Points between 3 and 10. For a while, we thought that this formula
does not work properly (#4862, #8950), but we recently discovered
that it seems to be working in some manner.
While an interesting and useful feature on its own, it has the side
effect that it leaks how popular your hidden service is. Since a
hidden service publishes a descriptor every hour, you can monitor
hourly usage patterns of hidden services. Of course, you can't get
the exact user count, but you might be able to get rough approximate
numbers (we still haven't analyzed the formula enough to know
*exactly* how much).
- During our recent work on hidden service statistics [0] people have
suggested to gather statistics that would get us closer to learn the
number of hidden service users [1]. The suggested way to do so is to
have HSDirs or introduction points count the total number of
introductions or descriptor fetches and publish that number in their
extra-info descriptor. Since given a hidden service address you can
easily learn its HSDirs or IPs, it should be possible to map those
statistics to specific hidden services, which would leak their
popularity (more on this later).
There might be more examples that I'm missing, but this should be
enough to demonstrate the leaks. For the rest of this post, I will be
presenting various arguments for and against leaking popularity.
Disclaimer: I still am not 100% decided here, but I lean heavily
towards the "popularity is private information and we should not
reveal it if we can help it" camp, or maybe in the "there needs to be
very concrete positive outcomes before even considering leaking
popularity". Hence, my arguments will be obviously biased towards the
negatives of leaking popularity. I invite someone from the opposite
camp to articulate better arguments for why popularity-hiding is
something worth sacrificing.
== Arguments for leaking popularity and reaping its benefits ==
Here are a few arguments that people use to shrug off popularity-hiding.
I can relate to some of them, but I find the reasoning of some others
funny or even dangerous.
- "If we don't care about leaking popularity we can get useful statistics"
Indeed, we've dismissed various statistics that we could collect
because we were afraid that they would leak the popularity of hidden
services. If we didn't have this fear, we would have a better idea
on how much usage hidden services see, or whether people are
conducting DoS attacks on hidden services.
- "If we don't care about leaking popularity we can get nice optimizations"
As an example, the dynamic IP calculation is one of those optimizations.
I'm not aware of other optimizations, but I bet that we can think of
a few more if we completely remove popularity-hiding from our threat
model. Also, people have claimed that more statistics would reveal
more optimizations that we could do.
- "Popularity-hiding is just a side-effect of the Tor protocol, and
not a stated security goal"
People have claimed that popularity-hiding is not a stated security
goal of hidden services, or that the name "hidden services" does not
imply popularity-hiding in any way.
- "There are no realistic attacks that could happen from leaking popularity"
People have claimed that popularity is just a curiosity, and nothing
bad can come from leaking it. They say that protecting popularity
does not offer security against realistic or dangerous attacks.
Other people claim that popularity-revealing attack vectors are too
noisy and contain too much random data, hence it's hard to get
targetted popularity values out of them. They say that it might only
be possible for very popular hidden services, or for unlikely edge
cases.
- "There are probably other ways to reveal popularity. You can't fix them all"
That's actually a big fear of mine. That we are nitpicking about 2-3
popularity revealing vectors, while there are hundreds more
currently open. See #8742 for example, but I bet there are more
vectors that we need to think about.
== Arguments for protecting popularity ==
And here are arguments that make me believe that popularity is
something that should be protected.
- Popularity attracts attention
Anonymity likes uniformity, but popularity attracts attention.
There are literally infinite possible use cases where a hidden
service wants to be public and still not attract attention.
However, since the above argument has not been particularly
successful and only attack demonstrations will persuade a true
skeptic's mind, here is an attack scenario:
Try hard to imagine a dystopian future where authorities are
tracking down and hacking activist websites. They just received a
big list of hidden services, the result of a messy interrogation,
but they are all locked. Their hackers can hack some of them but not
all. Not much time before revolution, end of dystopian future and
happiness for all humanity. The dictator needs to decide which
hidden services to hack to stop the revolution. Which??
With popularity being public , they can get the popularity of
the biggest ones and target those first.
- Popularity can be used to find patterns in group movements now and in the past.
Even though you can't track specific users using popularity, you can
still track group of users. Also, these statistics are forever: even
if you didn't care about a group of users in the past, but you start
caring about them now, you can still look back and see their
development over time.
Here is an attack scenario:
Imagine a community that practices very dangerous urban climbing [2].
Imagine thousands of friends climbing away in happiness from all
over the world,
Imagine now that this community splinters in other smaller
communities, if you monitor their popularity, it will be
possible for you to observe the movement of that subculture.
As a further point, imagine now that dystopian future comes and
very dangerous urban climbing gets outlawed. The police catches an
urban climber in New London and gets a list of hidden services from
her. They can then check _historically_ how many users those hidden
services had. They can basically notice all the trends of the urban
climbing scene in the past years. Creepy, no?
As you probably well know, anonymity is not a binary option. It's
not like you are not either super anonymous, or not. It's more of a
fuzzy variable that depends on many things. OPSEC is a big part of
anonymity, and it seems to me that popularity has OPSEC consequences.
- Statistics noise will get reduced. Attacks only get better.
In the statistics we were talking about, each HSDir would reveal the
number of descriptor fetches it received over the past day. We know
that each HSDir serves about 150 hidden services, which means that
the final value in the end will contain the popularity of 150 hidden
services in one number. This is expected to be extremely noisy, and
I think that's one of the main hopes of people who don't care about
popularity hiding. That allows them to claim that popularity will
only be leaked for very popular hidden services.
While this indeed seems reasonable, my main intuition is that
attacks can only get better. Here are some ways that noise can be
reduced. I will focus on the HSDir case, but same arguments apply
to other suggested statistics like number of introductions per IP.
-- It's still early in the hidden services scene, so not many
services get lots of traffic. I imagine that many of those 150
hidden services are going to be very inactive, and not provide much
noise.
-- Hidden services publish hidden service descriptors to 6 HSDirs.
This means that every day you will learn 6 noisy values for
your target hidden service, not just 1. It's easier to remove noise
that way.
-- Also, those 5 irrelevant hidden services that provide the noise
will publish themselves to 6 HSDirs. Applying the same logic as
above, you might be able to learn information about the noise, which
makes it easier to remove. In a way, you can put all the statistics
measurements in a big system of equations, and start solving it to
reduce noise in the equation you are interested in.
-- Think of crazy edge cases. Maybe an introduction point is very
weak and unlikely to be picked and only got 10 HSes for a day. If
one of them is the hidden service you are interested in, there is
going to be much fewer noise than usual.
-- There might be other techniques for reducing noise, by combining
other statistics (like the number of hidden services per HSDir which
is already a stat), or by influencing the statistics yourself (like
Aaron's attack on the stats aggregation protocol [3]).
What I'm trying to say here, is that if you thought that the urban
climbing example was ridiculous because such a community cannot be
big enough to be visible in noisy statistics, maybe by reducing
noise you can actually make it distinguishable.
- There are not that amazing benefits from ditching popularity-hiding.
To be honest, I have not heard convincing enough arguments that
would make me ditch popularity hiding. Some extra statistics or some
small optimizations do not seem exciting enough to me. Please try
harder. This could be a nice thread to demonstrate all the positive
things that could happen if we ditch popularity-hiding.
Also, there is a small difference here between the stats and the
introduction point formula. The dynamic introduction point formula
is something that we could disable by default, but also leave it as
a configurable option for people who want to use it. That is, it
will then be *the choice of the hidden service operator* whether he
cares about popularity being hidden or not. With the statistics that
have been proposed, you don't give any choice. You just do it for
all hidden services forever.
- Principle of least surprise
Hidden service operators except that hidden services are at least as
secure as the normal Internet plus more. On the normal Internet,
popularity is private by default. Having this assumption violated on
hidden services, might not be polite.
- Popularity-hiding is crucial to maintain the deep sea security model of hidden services
As I have mentioned in the past, some people think of the onion land
as a very deep ocean. In some places of the ocean, you might be able
to see some buoys (some more visible than others). To visit them,
you need to wear your goggles and your snokrel, dive in and enter
from underwater.
This might not seem like a very concrete security model, but in any
case popularity is not revealed at any point. The sea is opaque and
you can't see the divers entering the hidden services.
Anyway this post has grown to immense size, and I was really hoping it
would be shorter.
On a more practical note, over the next few weeks, we should decide
what we want to do with the dynamic introduction point formula and
whether we should keep it or not (#4862). My current intuition is that
it should be disabled but also kept there as an option for people who
want to enable it. In any case, I hope that this thread can stimulate
discussion.
Also, if you are a hidden service operator I'm curious to hear about
whether you believe that popularity hiding is a security property that
should be preserved if that's even possible.
Cheers!
[0]: https://blog.torproject.org/blog/some-statistics-about-onions
[1]: https://lists.torproject.org/pipermail/tor-dev/2015-February/008247.html
[2]: https://www.youtube.com/watch?v=kpS7vhvkIQM
[3]: https://lists.torproject.org/pipermail/tor-dev/2015-March/008404.html
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev