Hello,
we recently started discussing about further statistics that we could measure about hidden services [0]. We believe that most of the interesting statistics should be collected using a relay-hiding statistics aggregation scheme [1], but we were also thinking of any stats that could be collected in a more short-term fashion.
I will now enumerate the stats that Aaron considers interesting and low-hanging-fruit:
(1) Number of descriptor updates (total count and distribution) (2) Number of RPs established on relays (3) Number of circuits using TAP and nTor (4) Number of descriptors with encrypted introduction points
This time I'm going to put extra focus on how to use these statistics and _what questions they help us answer_. If these stats don't help us answer any interesting questions, they are not that useful. Also, this time we should have an *exact strategy* on how to use specific stats to derive the results we want, so that we don't spend 2 months after we write the code to figure out how to do extrapolations.
So here are some first thoughts. For each statistic I also include the preliminary analysis from the stats tech report [2]:
(1) Number of descriptor updates (total count and distribution) (Sec. 4.2.4)
Relays count how many descriptor updates they see per service. Assuming that stats are published daily (which is not necessary), this is going to be a number between 1 and 24 (since RendPostPeriod is currently one hour) and services pick a new directory after 24 hours (see rendcommon.c:get_time_period()).
Benefits This could reveal overall HS descriptor stability, which reflects the frequency of events causing descriptor updates, such as changing IPs or changing authentication keys. Also, this could reveal client errors or DoS attacks on HSDirs.
Risks Depending on how many HSes are behind each HSDir, this statistic might or might not reveal uptime information about specific services. Still it doesn’t seem like something we want to risk. Also, if the result is greater than 24, it means that an HS with modded RendPostPeriod was publishing to that HSDir (and that the HSDir doesn’t have many clients). Do we want to reveal that? OTOH, it seems to me that if the directory is serving many services, this statistic doesn’t really provide any insight. In addition, this could be used to reveal the 9introduction points used by a hidden service (assuming its address is known, but its descriptors are encrypted) by DOSing suspected IPs and observing in the responsible HSDirs report a higher number of descriptor updates.
[ohmygodel] Obfuscating this number by the maximum amount of descriptor updates per service that we would expect (so, 24) would provide reasonable privacy for the update frequency of any individual service while still providing a sufficiently accurate estimate of the average number of updates. This statistic would also be easily improved via anonymous statistics reporting.
I'm not yet convinced this is a useful stat. What is its use and which *questions* would it help us answer?
I'm assuming that we would total count here, since revealing the exact distribution could leak information about specific hidden services.
Also, this is related to the "Number of unique HSes per HSDir" statistic that we are already doing. This means, that we can do the division and arrive to "Average number of descriptor updates per HS". I'm not sure if I like this, since there are *specific* HSes corresponding to each HSDir. Are we sure that there are not edge-cases that this can be exploited to learn their uptime? I'm not.
(2) Number of RPs established on relays
Number of RPs established on relays (Sec. 4.3.3)
Relays report how many ESTABLISH_RENDEZVOUS cells they received.
Benefits The number of received ESTABLISH_RENDEZVOUS cells indicates how many connection attempts there are by clients to services that are running. This number is different from the number of descriptor fetches which happen when clients don't know yet whether a service is running, which will be omitted if clients still have a descriptor cached from a previous connection, and which we may not even gather because of privacy concerns. We can easily weight the number of ESTABLISH_RENDEZVOUS cells with the probability of choosing a relay as rendezvous point to estimate the total number of such cells in the network.
Risk This should be reported with a time delay so that it is unlikely that any existing rendezvous connections included in the statistic. Otherwise, it is possible that the adversary could attempt to disrupt existing connections at the RP as a DoS.
[ohmygodel] This seems straightforward and useful to collect, and it is closely related to the number of data cells at an RP, which we are already collecting.
OK, I can see how this stat would give us the number of "connection attempts there are by clients to services that are running". Is this a number we are interested in? I guess so maybe.
It seems related to the "How many hidden service clients are there?" question, which is obviously interesting, but it's not exactly there.
This stat seems more innocent to collect for the simple reason that clients pick RPs at random, so they don't correspond to specific hidden services like HSDir stats do.
However, there is again a correlation between "Number of RP cells" and this one. This would give the "Average number of cells per rendezvous circuit". To be honest, this might be a more interesting statistic than "number of RPs established", but it's more closely related to the application data of the hidden service circuit, so it should be analyzed with more scrutiny.
A relay-hiding statistics aggregation scheme would make this statistic easier to collect.
Number of circuits using TAP and nTor
Older clients (0.2.3.x) would build/extend circuits using TAP, newer clients would use nTor for that. IPs and RPs can report the number of introduction circuits that were built using either of the two methods. More precisely, relays would remember for each circuit how it was built, and as soon as they receive an \verb+ESTABLISH_INTRO+ or \verb+ESTABLISH_RENDEZVOUS+ cell, they increment one of two counters. See ticket 13466 for details.
Benefits We would learn what fraction of clients and what fraction of services run older tor versions (0.2.3.x or older).
Risks As tor-0.2.3.x gets less common and only a few hidden services still use it, an adversary would be able to track their introduction points by checking which relays still report TAP clients on their statistics.
[ohmygodel] We should be able to hide the effect of circuits from any one HS or client by adding obfuscation. Having IPs report statistics could reveal unknown IPs, however. Also, why not have all relays report this in addition to RPs? That seems useful and easy.
This statistic can reveal other information too since it's basically a circuit count. For example, if you count and publish the number of circuits containing ESTABLISH_INTRO, you get the "Number of IPs established on the network" statistic. If you count and publish the number of circuits containing ESTABLISH_RENDEZVOUS, you get the "Number of RPs established on relays" statistic I discussed in the previous section.
Also, why do we care how many hidden services are using older versions of Tor? And why do we care how many clients are using older versions of Tor? Is this to specifically detect botnet activity?
Also, why do this just for hidden services?
Number of descriptors with encrypted introduction points
Relays can look at published hidden-service descriptor and count descriptors with plain-text vs. encrypted introduction point sections.
Benefits We would learn what fraction of services uses authentication features. This statistic won't be available after implementing rend-spec-ng (224)
Risks There is no obvious risk from sharing this number if aggregated over a large enough time period.
[ohmygodel] Both the benefit and risk seem low here. Roger mentioned this statistic as being interested to him; maybe we should implement it for that reason alone.
This seems like a stat that would answer a very concete question "How many hidden services are using authorization currently?".
Answering this question seems useful for evaluating the user base and popularity of this feature.
However, I'm not sure if I want to learn this information at all. People who use hidden service authorization are cautious users, and it seems weird to count them like this. It might be okay if there are 10000 of these hidden services, but if there are only 100, I wouldn't want to out them like this. More thinking required.
[0]: https://lists.torproject.org/pipermail/tor-dev/2015-February/008228.html [1]: https://lists.torproject.org/pipermail/tor-dev/2015-January/008086.html [2]: https://people.torproject.org/~karsten/volatile/hidden-service-stats-2015-01...