Opened 7 months ago

Last modified 4 days ago

#30579 needs_information defect

Add more STUN servers to the default snowflake configuration in Tor Browser

Reported by: cohosh Owned by: cohosh
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords: stun, anti-censorship-roadmap-october
Cc: cohosh, dcf, arlolra, phw Actual Points: .3
Parent ID: #31281 Points: 1
Reviewer: Sponsor: Sponsor30-can

Description

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.

Child Tickets

Change History (19)

comment:1 Changed 7 months ago by cohosh

Cc: cohosh dcf arlolra phw added

comment:2 Changed 6 months ago by phw

Sponsor: Sponsor19Sponsor30-can

Moving from Sponsor 19 to Sponsor 30.

comment:3 Changed 5 months ago by gaba

Keywords: anti-censorship-roadmap-october added; snowflake removed

comment:4 Changed 5 months ago by phw

A friend suggested that we look into whatever gaming voice chat systems are popular in China. In the West, there's Discord and TeamSpeak but China probably has its own versions of these. The OTF summit may be a great venue to learn more about this.

comment:5 Changed 4 months ago by cypherpunks

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.

comment:6 Changed 4 months ago by 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.

See https://en.wikipedia.org/wiki/STUN#Limitations and https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation

comment:7 in reply to:  6 Changed 4 months ago by cohosh

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.

comment:8 Changed 4 months ago by cypherpunks

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.

comment:9 Changed 3 months ago by gaba

Parent ID: #31281

comment:10 Changed 5 weeks ago by cohosh

phw just pointed out in IRC that Steam has STUN servers: https://github.com/ValveSoftware/GameNetworkingSockets

comment:11 Changed 3 weeks ago by cohosh

Owner: set to cohosh
Status: newassigned

comment:12 Changed 3 weeks ago by cohosh

Okay it looks like Steam itself does not run STUN servers (or at least not public-facing ones) (yet). See:

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.

comment:13 Changed 3 weeks ago by cohosh

Status: assignedneeds_information

Here are some lists of public servers:

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.cn

This 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)?

comment:14 Changed 3 weeks ago by cohosh

Actual Points: .3

comment:15 in reply to:  13 ; Changed 2 weeks ago by phw

Replying to cohosh:

Here are some lists of public servers:


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)?


Is the idea to have the broker hand STUN servers to the client over the domain-fronted connection?

Last edited 2 weeks ago by phw (previous) (diff)

comment:16 in reply to:  15 Changed 2 weeks ago by cohosh

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)?

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.

Last edited 2 weeks ago by cohosh (previous) (diff)

comment:17 Changed 13 days ago by cypherpunks

What about domain fronting STUN requests?

comment:18 in reply to:  17 Changed 13 days ago by cohosh

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.

comment:19 Changed 4 days ago by dcf

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.

Note: See TracTickets for help on using tickets.