Measuring reachability of default obfs4 bridges

[Em4E]

hellais suggested that OONI could help with our project on measurement of default Tor Browser bridges.

Here is the set of destinations we are currently measuring: proxy-probe.txt

This list of bridges doesn't need to be kept confidential; it consists of already deployed and soon-to-be-deployed default Tor Browser bridges; i.e., the bridges that are hardcoded in the source code. We would love to have OONI testing the reachability of these destinations from many vantage points.

For these tests, we are only doing TCP reachability (with a 30 s timeout), not a full obfs4 handshake. So if possible, that's what we would like OONI to do too. Doing a full obfs4 handshake could be interesting too, but it would be more useful for us to have simple TCP reachability working in a shorter time frame.

[bassosimone]

My though on this is that, if the obfs4 handshake is reasonably low on complexity (for example if it uses either a binary or a string protocol and entails just some messages) and/or if the crypto needed to implement it is either already part of libressl or a small library (like those curve libraries), then I believe the handshake itself could be implemented as a measurement-kit test — and then, in turn, we can pull this obfs4-handshake test into ooni-probe when we'll start using measurement-kit as its engine.

[anadahz]

Have you seen the Bridge reachability test ?

[hellais]

Hey @Em4E thanks for writing up this ticket.

I think going for implementing this as a set of inputs for the tcp_connect test is the best way to got.

What I would do to implement this is the following:

• [x] Add a tcp_connect test with the required inputs to the tor deck that we are currently shipping as part of ooniprobe (I would advise we also annotate the reports with something meaningful so that we can easily search for the ones relevant to this test).
• [x] Update ooni-resources to provision probes with this new input and deploy an update to support this.

In going forward I think we should investigate the option of packaging obfs4proxy (together with lantern and psiphon) as a static go binary inside of ooniprobe itself so that we can do more thorough testing of it.

I am quite against the idea of having our own implementation of obfs4 (or any other CCT) technology as part of ooniprobe (or measurment-kit) as it will require a considerable amount of effort to maintain it and ensure it's exactly the same as what real users are running at a given point in time.

Have you seen the Bridge reachability test?

I don't think bridge reachability is currently in a state where it's easily deployable. It has a bunch of dependencies that we don't ship as part of ooniprobe, so we can't ensure that we will have full coverage in terms of testing.

[Em4E]

Thanks @hellais, implementing as a tcp_connect test will be great.

bridge_reachability is not that interesting to us: it's a nice idea but there aren't any probes running it, and there haven't been for a long time. Simple reachability is like 80% of what we could want and it's more valuable to have it sooner than later.

There are interesting things happening with the bridges even now; the GFW apparently changed its discovery methodology and blocked a subset of them on October 20. That's based on observations from just one site in China. It would be good to have visibility across other countries too.

[hellais]

ooniprobe 2.1.0 that includes this is now out!

We have started to collect this data and will within 24 hours start seeing it in the collected measurements.