Re: [tor-relays] Current state of HSDir attacks on hidden services

[Roger Dingledine <arma@xxxxxxx>]

On Wed, Dec 12, 2018 at 02:59:34PM -0500, Jonathan D. Proulx wrote:
> Is it really still the case that spending a little time crafting
> the "right" finger prints i sall it takes for an adversary to
> reliably host the HSDir for a given hidden service? Well and
> 4-5 days uptime...

For the "legacy" v2 onion service design, yes. But for the v3 onion
service design, this class of attack does not work: the HSDirs for v3
onion services are unpredictable until the day of, because one of the
inputs to the hash function that determines the HSDirs is the daily
global shared-random-value:
https://gitweb.torproject.org/torspec.git/tree/srv-spec.txt

I guess in theory we could do a flag day and make everybody who upgrades
use this shared-random-value as part of the hash for determining HSDirs
for v2 onion services too. But it would probably result in a lot of
unhappy people, and anyway v2 has other problems too, like its keys are
way too short, so we'll be happiest if we just let it die out over time.

Another option would be to not worry about relays that appear to be trying
to attack v2 onion services, on the theory that if you want your onion
service to not be attacked, you should move to v3. The problem there is
that if people are running relays for reasons other than "I want to help
grow the network and keep people safe", then they're not going to have
the right motivations when it comes to other situations where we want
relay operators to act with the safety of users in mind. They've already
signaled to us that they aren't part of our community, so let's use that
information and not wait to find out what else they will do that we don't
like. ("When someone shows you who they are, believe them the first time"
and all that.)

> Assuming the new ColoCrossing nodes are maliciously target ina
> particular hidden service is it just their sloppiness of putting
> them all up in the same place over a short period rather than in
> a slower and more widely distributed manner the only thing that
> prevented them from acheving their unmasking goals?

Two answers:

(A) No, there are scripts we can run to look for fingerprint similarity,
and those scripts don't depend on when the relays joined the network.
See also this paper:
https://nymity.ch/anomalous-tor-keys/

and

(B) You said unmasking, but in its simple form, this attack is about
either measuring popularity of a service or about censoring it. If you get
to be some of the HSDirs for your target onion address, you can measure
its popularity (by counting anonymous lookups). If you get to be all six
of its HSDirs for a day, you can censor that onion address for the day
(by just sending "nope, never heard of it" in response to all lookups).

That said, you could combine "become some of the HSDirs for a particular
onion service" with "run a bunch of guards" and then do correlation
attacks to see if your guards have any clients that are fetching the onion
descriptor from the HSDir (or if you're super lucky, have any clients that
are *posting* the onion descriptor to the HSDir). But if you're patient
(and you already are because in this scenario you're running a bunch of
guards for long enough that they accumulate users), you could also wait
until the day where one of your relays randomly becomes the HSDir for
the onion service in question, which would take longer but not require
any relay key placement attack.

Hope that helps,
--Roger

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays