Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 974
    • Issues 974
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 26
    • Merge requests 26
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #18800
Closed
Open
Issue created Jan 15, 2022 by intrigeri@intrigeriMaintainer17 of 17 checklist items completed17/17 checklist items

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 :/
Edited Mar 20, 2022 by intrigeri
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking