[tor-bugs] #10969 [Core Tor/Tor]: Set of guard nodes can act as a linkability fingerprint

[Tor Bug Tracker & Wiki]

#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