Lynn Tsai and I, with the help of others, have been measuring how long it takes for Tor Browser's default bridges to be blocked.
https://arxiv.org/abs/1605.08808 (click "PDF")
Abstract: Censors of the Internet must continually discover and block new circumvention proxy servers. We seek to understand the pace of this process, specifically, the length of the delay between when a proxy becomes potentially discoverable and when the censor blocks it. We measure this delay by testing the reachability of previously unseen Tor bridges, before and after their introduction into Tor Browser, from sites in the U.S., China, and Iran, over a period of five months. We find that China's national firewall blocks these new bridges, but only after a varying delay of between 2 and 18 days, and that blocking occurs only after a user-ready software release, despite bridges being available earlier in source code. While the firewall notices new bridges in Tor Browser, bridges that appear only in Orbot, a version of Tor for mobile devices, remain unblocked. This work highlights the fact that censors can behave in unintuitive ways, which presents difficulties for threat modeling but also opportunities for evasion.
The best summaries are on pages 4 and 5, which show in graphical/tabular form the dates of releases and how long the bridges remained reachable after. We would appreciate any comments or corrections. In particular, the description of the Tor Browser release process could stand some fact-checking by a Tor Browser developer.
On Mon, May 30, 2016 at 05:53:10PM -0700, David Fifield wrote:
Lynn Tsai and I, with the help of others, have been measuring how long it takes for Tor Browser's default bridges to be blocked.
As always, great work!
I find it odd that the diurnal blocking pattern seems to change over time. For example, ndnop3:24215 in Figure 1 seems completely unaccessible at first. A couple of days later, the diurnal pattern seems to kick in.
On what looks like February 20 and March 15, all bridges seemed accessible for a short amount of time from within China -- but also LeifEricson:41213 for your control machine. I am curious how these two events relate?
Two typos:
- "[...] before a public release or Tor Browser [...]" s/or/of/ - "Despite bridge being merged [...]" s/bridge/bridges/
On Wed, Jun 01, 2016 at 10:51:43AM -0400, Philipp Winter wrote:
On Mon, May 30, 2016 at 05:53:10PM -0700, David Fifield wrote:
Lynn Tsai and I, with the help of others, have been measuring how long it takes for Tor Browser's default bridges to be blocked.
As always, great work!
I find it odd that the diurnal blocking pattern seems to change over time. For example, ndnop3:24215 in Figure 1 seems completely unaccessible at first. A couple of days later, the diurnal pattern seems to kick in.
We don't know what's causing it. It might be changing routes, for example. We unfortunately don't have traceroutes. Or perhaps one of their load balancers is dodgy, and they re-hashed everything on those days.
I found it reminiscent of your paper, https://petsymposium.org/2015/papers/01_Ensafi.pdf particularly Fig. 7 and Table 1, which show bursty failures of the firewall ("This shows that No-packets-dropped cases generally happen in bursts of hours"). Though Roya said that particular measurement only lasted a day so you wouldn't have been able to see any patterns.
On what looks like February 20 and March 15, all bridges seemed accessible for a short amount of time from within China -- but also LeifEricson:41213 for your control machine. I am curious how these two events relate?
The LeifEricson:41213 line in the figure is being scanned from China. It's under "controls" not because it depicts the results from our U.S. probe site, but because it was not added as a new bridge during the experiment (it was already blocked when we started). Perhaps "controls" is a bad way to label it on the figure. Everything in Figure 1 is reachability from China.
We don't know what caused those brief periods of reachability. I can only guess that they are temporary failures of the GFW.
Curiously, the brief span on reachability on March 27, visible in the graph, coincides with a publicly reported GFW failure. http://www.scmp.com/tech/china-tech/article/1931301/google-breaks-through-ch... The news article says Google was reachable from 15:30 to 17:15 (UTC). The bridges were reachable from 10:00 to 18:00 (UTC).
tor-project@lists.torproject.org
-
David Fifield -
Philipp Winter