[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #30579 [Circumvention/Snowflake]: Add more STUN servers to the default snowflake configuration in Tor Browser
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs