Fix bug in obfs4proxy (Elligator2), upgrading to 0.0.12+

https://lists.torproject.org/pipermail/anti-censorship-team/2022-January/000213.html

tl;dr:

All existing versions prior to the migration to the new code (anything that uses agl's code) are fatally broken, and trivial to distinguish via some simple math.

• What we know
• What we would like to know
• To Do

What we know

• obfs4proxy 0.0.11 (+ some commits) worked fine with Chutney
• obfs4proxy 0.0.12 doesn't work reliably on some test systems

  • This is known upstream (http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/tor-browser/-/issues/40804) although there, tor eventually bootstraps

  • Chutney:

    • This problem happens very often with TOR_SIGNOFLIFE_TIMEOUT=10
    • TOR_SIGNOFLIFE_TIMEOUT=120 allows tor to bootstrap further and even to often succeed bootstrapping.

  • Real Tor network:

    • This problem rarely happens (1/10) with TOR_SIGNOFLIFE_TIMEOUT=120

What we would like to know

• Does this problem happen on the real Tor network with TOR_SIGNOFLIFE_TIMEOUT=10?

• Would upgrading obfs4proxy server side fix the reliability issue on Chutney?

  • Censorship team meeting logs suggest it might be the case, but they're not sure yet.

• Which users would be affected if we bump TOR_SIGNOFLIFE_TIMEOUT when obfs4 bridges are selected?

• Does obfs4proxy 0.0.13+ work fine on Chutney?

  • TODO: Check if it's in a Tor Browser build (alpha?)? → no
  • not many changes between 0.0.12 and 0.0.13, so maybe doesn't make a difference, although the utls removal might fix stuff, who knows

• Does obfs4proxy 0.0.12 work fine on the real Tor network? we think so, but we are not sure

  • TODO: Extract info from the +real-Tor branch (boyska)
    • some build failed: 11,10,9,3; I don't see traces of "Proxy Client" in .journal, but I never found the ".tor" file

• Which Chutney version or configuration option would make obfs4proxy 0.0.12 work fine?

• Was any such thing reported to upstream obfs4proxy recently?

  • check this (issues, MRs, commits) on https://github.com/Yawning/obfs4 : nothing found

• Was any such thing reported to upstream Tor Browser recently?

  • TODO: check this (issues, MRs) [intrigeri]
    • yes: http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/tor-browser/-/issues/40804

• Has Tor Browser done any related change?

  • TODO: check the tor-browser-build Git history [intrigeri] → no

To Do

• Try bumping TOR_SIGNOFLIFE_TIMEOUT even more [intrigeri]
  • done on the 18800-obfs4proxy-elligator2-bump-timeout branch
  • done on the debug-obfs4proxy-real-Tor branch
• Investigate via obfs4proxy debug logs
  • goal: see if it's the same problem as http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/applications/tor-browser/-/issues/40804
  • Enable obfs4proxy debug logs [boyska]
    • how: ClientTransportPlugin obfs4 exec ./obfs4proxy -enableLogging -unsafeLogging -logLevel DEBUG
  • Check if the same problem occurs when using Chutney
  • Check if the same problem occurs when using the real Tor network
  • Check if tor manages to bootstrap on the real Tor network with obfs4proxy 0.0.12 and an increased TOR_SIGNOFLIFE_TIMEOUT
  • Report on the tor-browser issue (and cross fingers?)
• Look at all our debug branches and cherry-pick whatever we want to salvage from them
  • Enable obfs4proxy logging by default? If so, with which -logLevel? With or without -unsafeLogging? → !734 (merged)
  • 01b80586: candidate for the real Tor network branch
  • Have our test suite save obfs4proxy logs when relevant (if they exist) → !734 (merged)
  • 2576b852 → !734 (merged)
• Check whether upgrading obfs4proxy server side fixes the reliability issue on Chutney
  • Not possible without lots of backports :/