[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #10969 [Core Tor/Tor]: Set of guard nodes can act as a linkability fingerprint
#10969: Set of guard nodes can act as a linkability fingerprint
-------------------------------------------------+-------------------------
Reporter: asn | Owner:
| mikeperry
Type: defect | Status:
| reopened
Priority: High | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-client, tor-guard, XKEYSCORE, | Actual Points:
prop259, SponsorU-deferred, QUICKANT |
Parent ID: | Points: large
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by cypherpunks):
Replying to [comment:48 cypherpunks]:
> There were two problems you seemed to be interested in, 1) finding
something that suits your needs (you're using Tor, right?), 2) finding out
whether the proposed fix for this ticket was sufficient. My earlier
comment was related to the first issue only.
Thanks for trying to help, but my comments written here in the first
person were not a request for help with my personal needs but rather an
attempt to illustrate a general shortcoming of Tor that I think should be
improved for all users.
> > How many Snowflake users do you think there are in my city? I would
guess that there are not a lot. Also, from reading #21312, it doesn't
sound like Snowflake is quite production-ready anyway.
>
> You're misunderstanding how Snowflake operates: From a local network
observer frame of reference, you first connect to some domain front, then
you connect to one of the many short-lived Snowflake bridges, and its
fingerprint looks like WebRTC. What may distinguish Snowflake for your
situation is that the IPs you'll connect to will change **a lot**.
>
> Again read the documentation to see whether it would suit your needs:
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/SnowFlakeEvaluation
I don't think I'm misunderstanding how Snowflake works. Snowflake does
change the threat model for this issue a bit. Against a local-city
adversary who sees only coarse connection data (4-tuples and timestamps,
say) who wants to track your location, yes, I think it is probably better
than using a guard even if there aren't other Snowflake users (assuming
that the domain fronting and STUN hosts are commonly used in that city).
If the adversary has netflow data, though, or if your adversary is at the
domain fronting host, then they can presumably fingerprint you as a
snowflake user (aka "that" snowflake user, when you're the only snowflake
user in town). And unlike with guards, with the snowflake domain fronting
host, you don't have a bunch to choose from and the ability to rotate
them.
But, more importantly, I think moreso than with any other transport,
Snowflake exposes you to attacks by active adversaries who would like to
become your first hop (unless I'm mistaken, it's way worse than
`UseEntryGuards 0`, no?).
Anyway, unless there is a proposal to make Snowflake the default Tor
transport (which I would strongly oppose for the reason stated in the
previous sentence!), this ticket isn't about Snowflake. If you want to
further discuss any of the Snowflake issues I've just mentioned here, you
could link from here to other appropriate new or existing tickets and I
might weigh in.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10969#comment:49>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs