[tor-bugs] #30579 [Circumvention/Snowflake]: Add more STUN servers to the default snowflake configuration in Tor Browser

[Tor Bug Tracker & Wiki]

#30579: Add more STUN servers to the default snowflake configuration in Tor Browser
-------------------------------------------------+-------------------------
 Reporter:  cohosh                               |          Owner:  cohosh
     Type:  defect                               |         Status:
                                                 |  needs_information
 Priority:  Medium                               |      Milestone:
Component:  Circumvention/Snowflake              |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  stun, anti-censorship-roadmap-       |  Actual Points:  .3
  october                                        |
Parent ID:  #31281                               |         Points:  1
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor30-can
-------------------------------------------------+-------------------------

Comment (by cohosh):

 Replying to [comment:15 phw]:
 > > I suppose there's some risk here with choosing a random service.
 Snowflake clients leak their IP address to whichever server we choose.
 > [[br]]
 > I'm afraid I don't have great answers but only more questions:
 >
 > Assume we're using stun.foo.bar, which is owned by a third party. How
 easy would it be for the operator of stun.foo.bar to tell apart snowflake
 clients from the preexisting user base? I suppose the way we're making
 STUN requests may set us apart from other STUN clients?
 That's a good question, and one that would be useful to investigate as a
 part of our analysis of snowflake.

 The short answer is: the STUN requests don't have any reason to be
 different from the existing user base, and if they are we should change
 how they do things.

 The long answer is: STUN requests don't occur in isolation and it's almost
 certainly true that the rest of our client traffic does match the client
 traffic of the preexisting user base of the STUN servers we're using.
 >
 > Also, what's the worst a malicious STUN server could do? Publish a list
 of IP addresses of snowflake clients? Lie to the clients, so NAT traversal
 won't work? Anything else? As I understand it, a censor can already do all
 these things (assuming an active adversary) but granted, it's easier to do
 if the censor controls the STUN server.

 I guess I'm nervous because of all the steps we take in e.g., metrics
 collection to protect individual IP addresses/geolocation/any information
 at all of Tor clients. You're right that a censor can already do all these
 things, but we're potentially making their job easier, and giving that
 information out to more than just censor actors.
 >
 > I think this is a good topic to discuss for next week's anti-censorship
 meeting. I added it to our meeting pad.
 Sounds like a good idea, thanks!
 > > Perhaps a better route is to have the broker perform this step over
 the domain fronted connection (#25591)?
 > Is the idea to have the broker hand STUN servers to the client over the
 domain-fronted connection?
 Not quite, the idea would be for the broker to fill the role of a
 STUN/TURN server and provide the client with their ICE candidates
 directly. I don't think this will be difficult to do and in fact pion
 already has an example that does this:
 https://github.com/pion/webrtc/tree/master/examples/pion-to-pion-trickle

 We'll have to look into whether the domain fronting of the broker
 complicates this, and refactor some of the negotiation code on the client
 side to send the offer before candidate collection has begun.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30579#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online