Opened 9 years ago

Closed 3 years ago

#1851 closed project (wontfix)

Learn which bridges can't reach baidu

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: blocking tor-bridge
Cc: phw Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I hear from our friends at GIFC that when their bridges get blocked, they get blocked duplex. That is, people in China can't reach the bridge, but also the bridge can't reach China. So one trick they have for checking if bridge addresses need to be rotated is pinging a well-known site inside China.

Now, this reachability testing won't solve all our problems. In practice, we know from #1728 that sometimes the gfw blocks our bridges much more precisely by ip:port rather than by blackholing the IP address.

On the other hand, we know that at least in the Sept 2009 blocking event, they blocked some bridges by ip:port and others by blackholing them:
http://archives.seul.org/tor/relays/Sep-2009/msg00003.html

So it would be worthwhile to teach bridges how to check if they've been blackholed, in case it turns out to be useful trick in the arsenal.

Step one is to come up with a proposal for how we're going to check. Should we just fetch the baidu frontpage at irregular times, and if we've failed too many tests lately but we otherwise seem to have a working network connection, add a line to our extra-info descriptor? What are the blocking-resistance implications of having all our bridges voluntarily touch baidu periodically?

Step 1.5 is to implement the proposal.

Step two is to run a few bridges ourselves, get them blackholed (perhaps by giving out their addresses in every single answer on bridgedb ;), and test to make sure the reporting behavior is working as expected.

Step three is to look for patterns in the extra-info descriptors that the bridge directories aggregate. Do the bridges that seem to have no traffic from China report that they can't reach Baidu? Corroborate by doing direct scans from inside China.

Step n, as a bonus, is to evaluate whether we want to get any more methodical about which domains we test. Maybe have a list of domains somewhere that bridges learn that we can update on the fly? We should save this question until we've at least finished step two.

Child Tickets

Change History (16)

comment:1 Changed 8 years ago by arma

I wonder if there's a way to send an extend request to the bridge such that we can discover the answer ourselves as just a client. Then we don't need to modify the Tor codebase at all.

comment:2 Changed 8 years ago by arma

Component: Tor RelayTor Bridge

comment:3 in reply to:  1 Changed 8 years ago by arma

Replying to arma:

I wonder if there's a way to send an extend request to the bridge such that we can discover the answer ourselves as just a client. Then we don't need to modify the Tor codebase at all.

Added as #2576.

comment:4 Changed 8 years ago by arma

See also #2614 for an earlier and related step in this process: trying to reach baidu from public exit relays, to get a better sense of whether duplex blocking is happening at all.

comment:5 in reply to:  description Changed 8 years ago by rransom

Replying to arma:

I hear from our friends at GIFC that when their bridges get blocked, they get blocked duplex. That is, people in China can't reach the bridge, but also the bridge can't reach China. So one trick they have for checking if bridge addresses need to be rotated is pinging a well-known site inside China.

Do the GIFC clients and bridges ignore TCP RST packets? If so, that alone will get their bridges blackholed by IP address -- the GFW's only method of blocking by TCP address (IP + port) is to send forged RST packets.

comment:6 Changed 8 years ago by nickm

Milestone: Deliverable-Mar2011Tor: unspecified

comment:7 Changed 8 years ago by karsten

Summary: Project: learn which bridges can't reach baiduLearn which bridges can't reach baidu
Type: taskproject

comment:8 Changed 8 years ago by runa

Milestone: Tor: unspecifiedSponsor E: March 15, 2012

comment:9 Changed 8 years ago by runa

Milestone: Sponsor E: March 15, 2012

comment:10 Changed 8 years ago by nickm

Milestone: Tor: unspecified

comment:11 Changed 8 years ago by nickm

Keywords: bridge blocking added

comment:12 Changed 7 years ago by nickm

Keywords: tor-bridge added

comment:13 Changed 7 years ago by nickm

Component: Tor BridgeTor

comment:14 Changed 6 years ago by arma

Keywords: bridge removed

comment:15 Changed 3 years ago by arma

Cc: phw added
Severity: Normal

phw: I'm thinking we should close this ticket, and maybe even the ones around it (like #2576 and #2614), since the time for this level of analysis is years out of date.

Agree/disagree?

comment:16 Changed 3 years ago by phw

Resolution: wontfix
Status: newclosed

I agree. The anecdotal evidence here seems outdated, and for now we have a pretty good understanding of how bridges are blocked. See, e.g., https://censorbib.nymity.ch/#Ensafi2015a

Note: See TracTickets for help on using tickets.