Summary of Point Break (Jansen et al. USENIX Security '19) as it pertains to bridges
Rob Jansen, Tavish Vidya, and Micah Sherr have a paper about bandwidth-based DoS against Tor. Section 5 is about default bridges. https://www.usenix.org/conference/usenixsecurity19/presentation/jansen https://www.usenix.org/system/files/sec19-jansen.pdf#page=6 While elsewhere in the paper they discuss in-protocol attacks, in the context of bridges they limit themselves to attacks using third-party paid "stresser" DoS services, which you can rent for about $1/Gbps/hour (Section 3.1). They looked at the default bridges in Tor Browser 8.0.3 (October 2018). Only 12 of 25 default obfs4 bridges were working. (I think most of the non-working bridges have since been pruned, e.g. in #29378, #30264.) The median bandwidth of the 12 working bridges was 368 KB/s, with a large variance: minimum of 67 KB/s and maximum of 1190 KB/s. Besides the default bridges, they requested 135 bridges from BridgeDB, and found that only 70% (95/135) of them worked. (This has also been at least partially addressed by #30441.) BridgeDB bridges are faster than default bridges, with a median bandwidth of closer to 600 KB/s (Figure 1). They estimate that disabling the 12 default obfs4 bridges would require 30 stresser jobs, at a rate of $22/hour or $17K/month. If all users of default obfs4 bridges switched to BridgeDB bridges, the median bandwidth of BridgeDB bridges would slow down to under 100 KB/s (Figure 2). If even half of default obfs4 users switch to using meek, the cost to operate meek will at least double (Figure 3).
Do we have data on bridge uptime, length of operation, and bandwidth capacity? (Or 2 of those 3?) Would it make sense to pool at our entire pool of bridges and contact operators about being default bridges from that pool, as opposed to our current ad-hoc request method? (Or do we do that already and I wasn't aware?) -tom On Sat, 24 Aug 2019 at 18:47, David Fifield <david@bamsoftware.com> wrote:
Rob Jansen, Tavish Vidya, and Micah Sherr have a paper about bandwidth-based DoS against Tor. Section 5 is about default bridges.
https://www.usenix.org/conference/usenixsecurity19/presentation/jansen https://www.usenix.org/system/files/sec19-jansen.pdf#page=6
While elsewhere in the paper they discuss in-protocol attacks, in the context of bridges they limit themselves to attacks using third-party paid "stresser" DoS services, which you can rent for about $1/Gbps/hour (Section 3.1).
They looked at the default bridges in Tor Browser 8.0.3 (October 2018). Only 12 of 25 default obfs4 bridges were working. (I think most of the non-working bridges have since been pruned, e.g. in #29378, #30264.) The median bandwidth of the 12 working bridges was 368 KB/s, with a large variance: minimum of 67 KB/s and maximum of 1190 KB/s.
Besides the default bridges, they requested 135 bridges from BridgeDB, and found that only 70% (95/135) of them worked. (This has also been at least partially addressed by #30441.) BridgeDB bridges are faster than default bridges, with a median bandwidth of closer to 600 KB/s (Figure 1).
They estimate that disabling the 12 default obfs4 bridges would require 30 stresser jobs, at a rate of $22/hour or $17K/month. If all users of default obfs4 bridges switched to BridgeDB bridges, the median bandwidth of BridgeDB bridges would slow down to under 100 KB/s (Figure 2). If even half of default obfs4 users switch to using meek, the cost to operate meek will at least double (Figure 3). _______________________________________________ anti-censorship-team mailing list anti-censorship-team@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-team
On Sat, Aug 24, 2019 at 07:46:27PM +0000, Tom Ritter wrote:
Do we have data on bridge uptime, length of operation, and bandwidth capacity? (Or 2 of those 3?) Would it make sense to pool at our entire pool of bridges and contact operators about being default bridges from that pool, as opposed to our current ad-hoc request method?
Yes, we have this data and I think that's a good idea. I filed the following ticket for it: <https://bugs.torproject.org/31523> Cheers, Philipp
On Sat, Aug 24, 2019 at 12:46:52PM -0600, David Fifield wrote:
They looked at the default bridges in Tor Browser 8.0.3 (October 2018). Only 12 of 25 default obfs4 bridges were working. (I think most of the non-working bridges have since been pruned, e.g. in #29378, #30264.) The median bandwidth of the 12 working bridges was 368 KB/s, with a large variance: minimum of 67 KB/s and maximum of 1190 KB/s.
Yes, we've been cleaning up our default bridges over the last few months. Here's an up-to-date list of our current default bridges: <https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/DefaultBridges>
Besides the default bridges, they requested 135 bridges from BridgeDB, and found that only 70% (95/135) of them worked. (This has also been at least partially addressed by #30441.) BridgeDB bridges are faster than default bridges, with a median bandwidth of closer to 600 KB/s (Figure 1).
For context: many obfs4 bridges had an unreachable obfs4 port because some operators were not aware that they had to expose both their OR *and* their obfs4 port. Our documentation wasn't sufficiently clear about this. We have since reached out to all affected operators. Many responded and fixed the issue. We eventually had to blacklist the bridges of the operators who did not respond. Cheers, Philipp
participants (3)
-
David Fifield -
Philipp Winter -
Tom Ritter