[tor-project] Automatic Circumvention For Briar

David Fifield david at bamsoftware.com
Wed Jul 18 23:54:38 UTC 2018

On Wed, Jul 18, 2018 at 03:22:11PM -0300, Torsten Grote wrote:
> Therefore, I looked into OONI vanilla_tor measurements from the past
> year and into the ratio of bridge users per country in the last three
> months with data from Tor Metrics. You can find the result here:
>     https://grobox.de/tor/  (needs JavaScript)

This is great, thanks for this.

> You will notice that Iran, Turkey and Venezuela are absent from both
> lists. Even China has a surprisingly high success rate. Do these
> countries maybe block the connections only later when the OONI probe
> doesn't listen anymore or is the blocking just very inconsistent? Tor
> Metrics also shows quite a few direct relay users in those countries.

For Turkey and Venezuela, at least, the reason is probably differing
implementations by various ISPs. As far as I know, the block in VE was
only by the one biggest ISP, CANTV--if it's easy, you may want to look
at success rate by AS. The same is true of Russia, where ISPs have to
implement the blocks and thus there are varying rates of effectiveness.
The same is true of web site blocks; viz.
where archive.org was ~60% accessible in RU, despite being supposed to
be blocked by all ISPs. Another nice example, from Greece, is
https://ooni.torproject.org/post/eeep-greek-censorship/ (see "Per ISP
analysis" figure).

Ultimately, "country" may be too coarse a distinction. We often use
"country" to approximate "region of uniform blocking policy," but
policies (de jure and de facto) differ within a country. An ISP or AS is
closer to what we want.

Raw success rates could also be misleading, because ooniprobes don't all
report with the same frequency. A stable probe reporting daily from a
relatively uncensored network will be overrepresented if you just look
at number of reports. OONI people may be able to speculate about whether
there is some kind of censoring effect in reporting: more censored
ooniprobes are less likely to be able to report their results (just a
hypothesis, I don't have any evidence).

> So once we know where Tor is likely to be blocked, we would like to know
> where bridges will work and which kind. The only data source for this
> that we found are the OONI tcp_connect measurements. You can find our
> results from the past year here:
>     https://grobox.de/tor/bridges.html  (needs JavaScript)
> This is looking at TCP connection success rates in some pre-selected
> countries compared to a control group. Only China seems to be
> interfering with bridge connections, but not with all and not all the time.
> When you only show Tor Browser bridges and even the ones with bad
> control group reachability, you will see that there's quite a few that
> perform very poorly. You might want to rethink including them.

Yes, the list hasn't been maintained in a while. It's interesting that
noisebridge01:46089 has less than 100% reachability in China. That's the
first (and only) default bridge to be added since the Tor Browser source
code moved to a different repository--we have evidence that the GFW was
scraping bridges from the source code in the previous repository. This
may mean they have gotten wise to the new location. It would be neat to
see a time series.

> I imagine that countries have other ways to interfere with bridge
> connections besides simple TCP blocking. If anybody is aware of reliable
> data sources for those, please let me know. Eventually, I would also be
> interested in knowing which pluggable transports work in which country.
> One-off academic research has limited usefulness here as we ideally have
> fresh data to decide parameters before each new Briar release.

It's old data, but I have a pile of measurements (TCP connect and obfs4
handshake) from Kazakhstan. TCP connect succeeds but obfs4 handshake
fails. I was also running ooniprobe from the KZ host (which was a VPN
endpoint in a gohost.kz datacenter).

> Which bridges should we include in Briar? The first impulse is to just
> use whatever Tor Browser is using, but on IRC somebody told me that
> those bridges are already overloaded and that we better request some
> through the usual channels. Is that the recommended approach?

If you use the same bridges as Tor Browser, then the blocking of Tor
Browser bridges will affect you too. You should have at least a few that
don't come from Tor Browser.

More information about the tor-project mailing list