Do a reachability check before polling for clients

added component::circumvention/snowflake owner::arlolra priority::medium resolution::fixed reviewer::cohosh severity::normal status::closed type::defect labels

There are even Iranian snowflakes, and guess what, they work.

Replying to cypherpunks:

There are even Iranian snowflakes, and guess what, they work.

Yep, and it's not surprising that snowflakes would work in places that block Tor. Many places that block access to public Tor relays don't effectively block pluggable transports.

There are a lot of challenges with doing something like the ticket describes. Keep in mind that:

the geoip database we use isn't perfect
keeping track of which proxies do and do not work in different regions is very difficult and as long as we have a lot of diverse snowflakes we probably don't need to do this (see https://trac.torproject.org/projects/tor/ticket/30350#comment:8)

It might make sense to have some logic at the client to make sure they aren't connecting to a proxy within their own censored region for safety purposes, but a widespread rejection of snowflakes in all regions that censor public Tor relays seems both unnecessary and unfeasible. There are many reasons why an individual snowflake won't work well for a client in addition being run in a place that blocks the bridge IP:

the snowflake could be maliciously or due to bugs unreliable
the snowflake could be outside the censored region but on an IP address blocked by the censor

We are working on other solutions to handle all of these problems (see #25429 (moved), #25723 (moved)). We're going for quantity and overall quality here and hoping that we can have a solution for the instances in which individual quality suffers.

That being said, we might say something on the web store to the effect that if you reside in a region that censors Tor, your snowflake probably won't be very useful and it may not be that safe for you personally to do so.

I was thinking about a "can it reach torproject.org? can it reach the directory servers?" as a metric indicative of whether it's in a censored region (which would even catch the cases when a snowflake is in a non-censored country but a censored network), but even that approach has its fair share of problems.

Replying to cypherpunks:

I was thinking about a "can it reach torproject.org? can it reach the directory servers?" as a metric indicative of whether it's in a censored region (which would even catch the cases when a snowflake is in a non-censored country but a censored network), but even that approach has its fair share of problems.

The snowflake proxy doesn't need to reach directory servers or torproject.org to work. It needs to reach the snowflake bridge(s) it knows about, and the snowflake broker though.

I like this idea. Changing the snowflake logic to test a connection to the bridge before polling and to disable if it is unreachable would solve some problems before they affect the client. And the snowflake of course won't get any clients at all if it can't reach the broker. We could also add some user-facing error message to let the operator know in the case though.

Replying to cohosh:

The snowflake proxy doesn't need to reach directory servers or torproject.org to work. It needs to reach the snowflake bridge(s) it knows about, and the snowflake broker though. I know but it's a good metric of knowing whether one is in a censored region since there tp.org and directory servers are usually blocked (one can even add a "proceed anyway?" option in case the bridge can be accessed).

Trac:
Description: I'm looking at https://trac.torproject.org/projects/tor/attachment/ticket/29461/example_metrics.log and I've seen one TR=2 and another TR=5 record. I'm not aware of the current situation in TR but as far as I remember Tor was censored there (it is even stated in the Torlauncher).

I propose to add a geoip check after the WebRTC check, and inform users in a list of censored countries that they can't run a snowflake proxy.

to

I'm looking at https://trac.torproject.org/projects/tor/attachment/ticket/29461/example_metrics.log and I've seen one TR=2 and another TR=5 record. I'm not aware of the current situation in TR but as far as I remember Tor was censored there (it is even stated in the Torlauncher).

We can have a snowflake do a reachability check of the bridge(s) and broker (and maybe Tor domains/dirauths) before trying to poll for clients. If this check fails, we should display a user-facing error message or warning and hold off on polling while the bridge is unreachable
Summary: Block censored countries from running snowflakes to Do a reachability check before polling for clients

Replying to cypherpunks:

Replying to cohosh:

The snowflake proxy doesn't need to reach directory servers or torproject.org to work. It needs to reach the snowflake bridge(s) it knows about, and the snowflake broker though. I know but it's a good metric of knowing whether one is in a censored region since there tp.org and directory servers are usually blocked (one can even add a "proceed anyway?" option in case the bridge can be accessed).

We should be careful about how we message this since there could be many reasons for network failure that aren't related to censorship.

Trac:
Owner: N/A to arlolra
Status: new to assigned

Replying to cohosh:

Changing the snowflake logic to test a connection to the bridge before polling and to disable if it is unreachable would solve some problems before they affect the client. And the snowflake of course won't get any clients at all if it can't reach the broker. We could also add some user-facing error message to let the operator know in the case though.

I agree, testing the bridge directly is the way to go. No need to test other torproject.org domains.

The "test" could even be the proxy speculatively making a WebSocket connection to the bridge and holding it idle until it gets a client--although that means the bridge would have thousands of idle connections at any time. Maybe it's better to just do a "probe" WebSocket connection at startup and then disconnect it.

Maybe it's better to just do a "probe" WebSocket connection at startup and then disconnect it.

Went that route.

Here's a start on this, https://github.com/keroserene/snowflake/commits/trac31391

Still need to copy over the changes to the badge but that's enough for tonight.

Here's a start on this, https://github.com/keroserene/snowflake/commits/trac31391

Ok, pushed a few more commits. Probably ready for someone to look at.

Trac:
Status: assigned to needs_review

Trac:
Reviewer: N/A to cohosh

The code looks good to me, and is ready to merge. I like the refactoring changes you made the websocket class and putting both missingFeature checks in the initToggle.

I tested this out and it looks great. I like that in addition to displaying the message, it also prevents the user from retrying to enable the webextension. However, I'm wondering about the use case in which a user sees the message that WebRTC has been disabled, goes into their about:config to enable it, and then cannot redo the check without restarting their web browser.

Perhaps a solution to any possible confusion here or with the error messages in general would be a short FAQ section for all of our missing feature error messages on snowflake.torproject.org (which the user arrives at by clicking on the "Learn more" link).

Trac:
Status: needs_review to merge_ready

However, I'm wondering about the use case in which a user sees the message that WebRTC has been disabled, goes into their about:config to enable it, and then cannot redo the check without restarting their web browser.

This was brought up in comment:5:ticket:31109 as well.

At present, if the PeerConnection constructor is in scope and then you toggle off media.peerconnection.enabled, you can still make a connection. My point being that a configuration hidden behind about:config might benefit from a browser restart since it's unclear how they're intended to be used.

Perhaps a solution to any possible confusion here or with the error messages in general would be a short FAQ section for all of our missing feature error messages on snowflake.torproject.org (which the user arrives at by clicking on the "Learn more" link).

Filed as #31902 (moved)

Trac:
Status: merge_ready to closed
Resolution: N/A to fixed

Noting that commits ending in https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=8d81270a9f217a5d0867a5db9237a02c8498eef9 got merged here.

I just did another health check using the modification to bridgetest here. I'm not getting failures from only ~1/3 of snowflake proxies which seems like a small improvement.

closed

mentioned in issue #31960 (moved)

mentioned in issue #33112 (moved)

mentioned in issue #33666 (moved)

moved to tpo/anti-censorship/pluggable-transports/snowflake#31391 (closed)

mentioned in issue tpo/anti-censorship/pluggable-transports/snowflake-webext#44 (closed)

Do a reachability check before polling for clients

Child items ...

Activity