Opened 11 months ago

Closed 9 months ago

Last modified 9 months ago

#31391 closed defect (fixed)

Do a reachability check before polling for clients

Reported by: cypherpunks Owned by: arlolra
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords:
Cc: arlolra, cohosh, phw, dcf Actual Points:
Parent ID: Points:
Reviewer: cohosh Sponsor:

Description (last modified by cohosh)

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

Child Tickets

Change History (16)

comment:1 Changed 11 months ago by cypherpunks

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

comment:2 in reply to:  1 Changed 11 months ago by cohosh

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:

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, #25723). 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.

Version 0, edited 11 months ago by cohosh (next)

comment:3 Changed 11 months ago by 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.

comment:4 in reply to:  3 ; Changed 11 months ago by cohosh

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.

comment:5 in reply to:  4 ; Changed 11 months ago by 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).

Last edited 11 months ago by cypherpunks (previous) (diff)

comment:6 Changed 11 months ago by cohosh

Description: modified (diff)
Summary: Block censored countries from running snowflakesDo a reachability check before polling for clients

comment:7 in reply to:  5 Changed 11 months ago by cohosh

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.

comment:8 Changed 11 months ago by arlolra

Owner: set to arlolra
Status: newassigned

comment:9 in reply to:  4 Changed 11 months ago by dcf

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.

comment:10 Changed 10 months ago by arlolra

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.

comment:11 Changed 10 months ago by arlolra

Status: assignedneeds_review

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.

comment:12 Changed 10 months ago by cohosh

Reviewer: cohosh

comment:13 Changed 9 months ago by cohosh

Status: needs_reviewmerge_ready

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

comment:14 Changed 9 months ago by arlolra

Resolution: fixed
Status: merge_readyclosed

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

comment:16 Changed 9 months ago by cohosh

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.

Note: See TracTickets for help on using tickets.