----- Forwarded message from isis <[email protected]> ----- > From: isis <[email protected]> > Subject: [otf-active] January 2016 Report for Tor Bridge Distribution > Date: Thu, 11 Feb 2016 17:22:14 +0000 > Message-ID: <[email protected]> > To: [email protected], [email protected] > Cc: isis <[email protected]> > > Hello, > > In January 2016, I worked mostly on "little-t tor" code (the actual tor source > code, as opposed to some other Tor Project codebase), as well as a bit of work > on Tor Browser's code for handling the builtin Bridges. Here are the hilights: > > - Finished implemention — as well as refactoring after review — of a new > feature for Tor Bridge relays, called "Bridge Guards". [0] > > The problem is best outlined by a 2012 paper [1] by some researchers in > China > who determined that the best methods for scraping Bridges out of BridgeDB > for > two weeks would yield the same amount of Bridges as running a Tor middle > relay. In this approach, the adversary only needs to run a middle relay > (which anyone can easily do, without the waiting periods required for > running > a Guard relay) and wait for connections from relays which are not listed in > Tor's consensus. These connections are pretty much guaranteed to be from > Bridge relays, since no Tor clients would be using that middle relay as a > Guard. Without counter-measures against this attack, any work to improve > BridgeDB's defenses against scraping would be less effective. > > The solution to this problem is super interesting! As we've known for some > time, Tor is actually loose-source routed. Essentially, this means that, > while we always say that a Tor client chooses her three hops — and this is, > of course, true, in that those hops must be used — nothing in the design of > Tor's circuit-level cryptography actually prevents extra, additional hops > from being inserted into the client's circuit, without even the client > knowing about it. As I mentioned, we've known Tor is loose-source routed > for > a long time, but we've never had a use for that accidental feature… until > now! :) My patches cause Bridges to select their own Guard node, and > inject > it into their clients' circuits. This means that middle relays now see the > Bridge Guard connecting to them, rather than the Bridge itself. (See Tor > Proposal #188 [2] for a full description.) > > - Assisted a Bridge relay operator in setting up two new obfs4 Bridges, and > patched Tor Browser to add them to the list of builtin Bridges. [3] [4] > > - Patched Tor Browser to change the default Pluggable Transport type to > obfs4, > [5] as well as to load-balance clients between the default Bridges. [6] > > [0]: https://bugs.torproject.org/7144 > [1]: Ling, Zhen, et al. "Extensive analysis and large-scale empirical > evaluation of tor bridge discovery." > INFOCOM, 2012 Proceedings IEEE. IEEE, 2012. > [2]: > https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt > [3]: https://bugs.torproject.org/18071 > [4]: https://bugs.torproject.org/18104 > [5]: https://bugs.torproject.org/18072 > [6]: https://bugs.torproject.org/18113 > > Best Regards, > -- > ♥Ⓐ isis agora lovecruft > _________________________________________________________ > OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 > Current Keys: https://blog.patternsinthevoid.net/isis.txt > > -- > You received this message because you are subscribed to the Google Groups > "otf-active" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/a/opentechfund.org/d/optout.
----- End forwarded message ----- -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
signature.asc
Description: Digital signature
_______________________________________________ tor-reports mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-reports
