Add more STUN servers to the default snowflake configuration in Tor Browser
Right now snowflake blocking in China is happening in the client's connection to the default STUN server (which is set to Google's STUN servers). We should add more STUN servers, including ones that are popular in regions that are trying to block snowflake so that blocking this stage causes more collateral damage.
Activity
Trac:
Parent Ticket: #31281 (moved)Hi. There is a better idea. Lot of popular and non-blocked websites put users' visible IP addresses in cookies, custom HTTP Headers or page body. Can we exploit this?
I imagine a system crawling websites automatically, finding user's visible IP addresses in their responses, generating the data describing how to carve and parse them and putting it into a repo. Then browsers fetch the repo, select a random webpage from the list, get it and parse the HTTP response.
Can we exploit this?
From my limited understanding, no. It's not enough to just know the external ip. The client needs to make an outgoing request in order for the NAT to add a mapping entry in its table between external ip:port pair and the client. That pair, returned in the response from the STUN server, is then communicated to the peer via some signalling method so that packets it sends to the external ip are translated to the client.
See https://en.wikipedia.org/wiki/STUN#Limitations and https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation
Replying to arlolra:
Can we exploit this?
From my limited understanding, no. It's not enough to just know the external ip. The client needs to make an outgoing request in order for the NAT to add a mapping entry in its table between external ip:port pair and the client. That pair, returned in the response from the STUN server, is then communicated to the peer via some signalling method so that packets it sends to the external ip are translated to the client.
Yep, it's not just the ip address but also the port that needs to be discovered, and set aside by the client for the purpose of the WebRTC connection.
Although, if there are popular P2P applications in areas that block Tor that aren't using STUN, but using something else for NAT traversal, it would be good to know and we might be able to modify the WebRTC library to use that (not sure if such a thing exists).
Since the STUN server (or other protocol server) that the client uses doesn't need to implement any custom code from us, and doesn't even need to know that it's being used for censorship circumvention, I think our best bet here is to use specific servers/protocols that are already popular for unblocked P2P applications instead of trying to roll our own thing.
It is worthless and may backfire. Censors would just contact the developers and say "implement measures preventing using your service for censorship circumvention or we will block your service too". This may include eliminating peer-to-peer calls entirely, streaming them through own servers and also implement recording and analysis of calls for surveillance and marketing needs.
Trac:
Parent: N/A to #31281 (moved)-
phw just pointed out in IRC that Steam has STUN servers: https://github.com/ValveSoftware/GameNetworkingSockets
-
Okay it looks like Steam itself does not run STUN servers (or at least not public-facing ones) (yet). See:
- https://github.com/ValveSoftware/GameNetworkingSockets#nat-piercing-icestunturn
- https://github.com/ValveSoftware/GameNetworkingSockets/issues/2#issuecomment-377643973
- https://github.com/ValveSoftware/GameNetworkingSockets/issues/64
It's also unclear whether Steam will eventually run a server that games developers can use or if game devs are expected to run their own servers. What we really want for this ticket are existing STUN servers that are already associated with popular services and therefore unlikely to be blocked.
-
Here are some lists of public servers:
- https://gist.github.com/zziuni/3741933
- https://gist.github.com/mondain/b0ec1cf5f60ae726202e
- https://www.voip-info.org/stun/
- EmerCoin is some cryptocurrency/blockchain project that uses STUN and they maintain their own list.
Some possibly useful candidates:
stun.services.mozilla.org
Mozilla's stun server is an obvious candidate, but I just checked it and it appears to not be working. I found this ticket while investigating: https://bugzilla.mozilla.org/show_bug.cgi?id=1143827
-
stun.gotye.com.cnThis appears to work. Looks like a new video/messaging/gaming service. See http://www.gotye.com.cn/
-
stun.stunprotocol.org
Idk, it's a .org domain and it works.
The most useful list seems to be from the coin project. I'd suggest referencing it again in the future and looking at STUN servers with TLDs in whichever region has blocked the ones we currently have in Snowflake (I saved a current snapshot at archive.org just in case)
I suppose there's some risk here with choosing a random service. Snowflake clients leak their IP address to whichever server we choose. Perhaps a better route is to have the broker perform this step over the domain fronted connection (#25591 (moved))?
Trac:
Status: assigned to needs_information 
Replying to cohosh:
Here are some lists of public servers:
- https://gist.github.com/zziuni/3741933
- https://gist.github.com/mondain/b0ec1cf5f60ae726202e
- https://www.voip-info.org/stun/
- EmerCoin is some cryptocurrency/blockchain project that uses STUN and they maintain their own list.
Thanks for compiling these lists! That's very useful.
I suppose there's some risk here with choosing a random service. Snowflake clients leak their IP address to whichever server we choose.
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?
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 think this is a good topic to discuss for next week's anti-censorship meeting. I added it to our meeting pad.
Perhaps a better route is to have the broker perform this step over the domain fronted connection (#25591 (moved))?
Is the idea to have the broker hand STUN servers to the client over the domain-fronted connection?
-
Replying to phw:
I suppose there's some risk here with choosing a random service. Snowflake clients leak their IP address to whichever server we choose.
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 doesn't 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 (moved))? 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.
-
Replying to cypherpunks:
What about domain fronting STUN requests? That's sort of what we're talking about above. Getting the broker to provide some STUN/TURN-like functionality makes more sense to me than tunnelling STUN requests through HTTP.
I didn't know this until just now, but RFC 5389 specifies STUN over TCP and/or TLS. So I suppose it would be possible to tunnel over domain-fronted HTTP or something similar.
mentioned in issue #32597 (moved)
mentioned in issue #34129 (moved)
mentioned in issue #31281 (moved)
mentioned in issue tpo/anti-censorship/pluggable-transports/snowflake#25591