[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #1851 [Tor Relay]: Project: learn which bridges can't reach baidu



#1851: Project: learn which bridges can't reach baidu
-----------------------+----------------------------------------------------
 Reporter:  arma       |       Owner:                     
     Type:  task       |      Status:  new                
 Priority:  normal     |   Milestone:  Deliverable-Mar2011
Component:  Tor Relay  |     Version:                     
 Keywords:             |      Parent:                     
-----------------------+----------------------------------------------------
 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1851>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs