Skip to content

Bridgestrap should recognize and report obfs4 version incompatibility

With the recent obfs4 bug where sometimes it fails to handshake (tpo/applications/tor-browser#40804 (closed)), we're going to want all the obfs4 bridges to upgrade to the new obfs4proxy version that we're getting into Debian. Once it's in Debian (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/33736) and we're doing our push to get bridge operators to upgrade, we're going to want a scalable way to recognize which bridges haven't upgraded, and tell their operators. Bridgestrap is already almost this tool.

Here are some plausible steps for getting there. Feel free to adjust this recipe in the face of reality or better ideas. :)

  • Upgrade bridgestrap's obfs4proxy to the new one. That way it will start having reachability issues with old (unupgraded) obfs4proxies, rather than the current situation where it has reachability issues with new (upgraded) ones.

  • Teach bridgestrap to recognize when it has learned that a given tested bridge is unupgraded. We recognize it because Tor gives us the Proxy Client: unable to connect OR connection (handshaking (proxy)) [...] RSA_ID=xxx complaint.

(To start, we can just listen to the WARN controller events and look for the string -- the RSA_ID param tells us which bridge had the problem. The better answer though is to involve the network team and see if they can give us some sort of more specific event, because the "manual string comparison" approach is brittle: if somebody changes the log message format, suddenly bridgestrap quietly breaks. Maybe a good enough compromise, in a world where C-Tor is freezing and Arti is the future, is to get a big comment added to that line in C-Tor saying that bridgestrap relies on that format and please check with bridgestrap before changing it.)

(We should also realize that the old version detection will be probabilistic, because sometimes the handshake will go fine and not send the WARN. That's ok, and imo bridgestrap's detection at this stage shouldn't try to get any smarter than "this time it worked" or "this time it flagged it as old".)

(In an ideal world we would have implemented tpo/core/tor#11101 in the past, and we wouldn't need to do these extra active measurement tests, and we could just look at the bridge's extrainfo descriptor to learn its obfs4 version. But we don't live in that world yet, so we should use this ticket as motivation to get that one done, but treat the two tickets separately.)

  • When a test flags the bridge as old, we should report this info in our findings. I think based on the discussion in #21 we should be able to annotate (via a new line, or a new field on the main line, or etc) a bridge as "pre-0.0.12" or something like that in the file that bridgestrap exports to metrics.

  • After that, we'll also want to change the bridges.torproject.org/status= output to not just say whether we found the bridge reachable, but also to call it out as old if we found it to be old.

(We could simply report the most recent result, so sometimes the page says you're ok when actually you're not; or we could try to do something smarter like "if any of the past k tests failed then we need to tell you" -- in which case we would want to include enough timestamps that the operator doesn't get confused when they upgrade but bridgestrap still complains to them -- talk to dgoulet and geko for their recent experience on reporting relay overload statuses to relay operators.)

  • Once we get to this point, we'll want to open a ticket for relay-search to do some similar notification mechanism on the bridge's status page. It will face the same question of how best to communicate with the human operator (do I look at the latest k results, which timestamps should I specify to be clear, etc).

  • After that, we'll also want to open a ticket for the network health community folks to start tracking the fraction of bridges that have / haven't upgraded. They can do this on their own by looking at bridgestrap's output file. Then they could run a campaign to get people to upgrade, or whatever they think is smartest at the time.