Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
bridgestrap
bridgestrap
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 4
    • Issues 4
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • The Tor Project
  • Anti-censorship
  • bridgestrapbridgestrap
  • Issues
  • #7

Closed
Open
Opened Nov 16, 2020 by Philipp Winter@phwOwner

Why does bridgestrap's success rate decrease when we test more bridges?

It appears that as we test more bridges at once, we're seeing more timeouts; or in other words: tor sees more NEWDESC events if we give it fewer bridges via SETCONF. Here's the setup I used:

  1. The results are based on Debian's Tor 0.3.5.10.

  2. Here's Tor's config file:

    UseBridges 1
    ControlPort unix:/tmp/tor-datadir-909036443/control-socket
    SocksPort auto
    SafeLogging 0
    Log info file /tmp/tor-datadir-909036443/tor.log
    DataDirectory /tmp/tor-datadir-909036443
    ClientTransportPlugin obfs2,obfs3,obfs4,scramblesuit exec /usr/bin/obfs4proxy
    Bridge obfs4 192.95.36.142:443 CDF2E852BF539B82BD10E27E9115A31734E378C2 cert=qUVQ0srL1JI/vO6V6m/24anYXiJD3QP2HgzUKQtQ7GRqqUvs7P+tG43RtAqdhLOALP7DJQ iat-mode=1
    Bridge obfs4 193.11.166.194:27015 2D82C2E354D531A68469ADF7F878FA6060C6BACA cert=4TLQPJrTSaDffMK7Nbao6LC7G9OW/NHkUwIdjLSS3KYf0Nv4/nQiiI8dY2TcsQx01NniOg iat-mode=0
    Bridge obfs4 37.218.245.14:38224 D9A82D2F9C2F65A18407B1D2B764F130847F8B5D cert=bjRaMrr1BRiAW8IE9U5z27fQaYgOhX1UCmOpg2pFpoMvo6ZgQMzLsaTzzQNTlm7hNcb+Sg iat-mode=0
  3. I used SETCONF to configure N bridges at a time and gave tor a maximum of 60 seconds to receive the respective NEWDESC events. If we didn't get a NEWDESC event in time, we label a bridge as "timed out." Once we hit the 60 second timeout, bridgestrap immediately SETCONFs the next batch of bridges.

For N=25, 721 (56.68%) out of 1,272 bridges were reachable (I tested a fairly old cached-extrainfo file). For N=100, 542 (42.61%) out of 1,272 bridges were reachable. When increasing the timeout to 120 seconds, the results for N=100 improve and we're seeing 673 (52.91%) out of 1,272 functional.

Note that we don't have ground truth about bridge reachability. I don't think the data has many (or any) false positives but it's likely to have false negatives.

I'm attaching the bridgestrap logs for N=25/60s, N=100/60s, and N=100/120s. @arma, you want to pay attention to the log lines that begin with C: and S:. These are control port interactions. C: should be limited to bridgestrap doing a SETCONF and S: is limited to SETEVENTS, ORCONN, and NEWDESC.

Edited Nov 17, 2020 by Philipp Winter
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: tpo/anti-censorship/bridgestrap#7