Opened 5 weeks ago

Last modified 3 weeks ago

#31391 assigned defect

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: 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 (9)

comment:1 Changed 5 weeks ago by cypherpunks

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

comment:2 in reply to:  1 Changed 5 weeks 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 and it may not be that safe for you personally to do so.

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

comment:3 Changed 5 weeks 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 5 weeks 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 5 weeks 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 5 weeks ago by cypherpunks (previous) (diff)

comment:6 Changed 5 weeks 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 5 weeks 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 5 weeks ago by arlolra

Owner: set to arlolra
Status: newassigned

comment:9 in reply to:  4 Changed 3 weeks 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.

Note: See TracTickets for help on using tickets.