Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • bridgestrap bridgestrap
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 10
    • Issues 10
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • bridgestrapbridgestrap
  • Issues
  • #7
Closed
Open
Created Nov 16, 2020 by Philipp Winter@phwReporter

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
Time tracking