[tor-dev] Should popularity-hiding be a security property of hidden services?

[David Stainton]

Hi George,

I read your post. I am a hidden service operator... and I feel
strongly that hiding popularity is in fact an anonymity property...
and security property. I also wonder if it's even possible to fully
hide popularity. I suggest we try to hide popularity at least until we
understand more about it and how to properly design hidden services.
(don't disallow what you cannot prevent philosophy)

You mention the "normal Internet" several times in your post...
positing that it's not possible to discover popularity. I'd like to
point out that your upstream ISP would have a solid notion of weather
or not your were operating a popular website... and by the way so
would xkeyscore most likely (you know... the single most important
revelation from the Snowden documents).

cheers,

David


On Fri, Apr 3, 2015 at 2:57 PM, George Kadianakis <desnacked at riseup.net> wrote:
> 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev