Skip to content

GitLab

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.

Open
Created by Philipp Winter@phwMaintainer

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 by Philipp Winter