[tor-reports] Fwd: [otf-active] January 2016 Report for Tor Bridge Distribution

[isis]

----- Forwarded message from isis <isis at torproject.org> -----

> From: isis <isis at torproject.org>
> Subject: [otf-active] January 2016 Report for Tor Bridge Distribution
> Date: Thu, 11 Feb 2016 17:22:14 +0000
> Message-ID: <20160211172214.GA18240 at patternsinthevoid.net>
> To: otf-projects at opentechfund.org, otf-active at opentechfund.org
> Cc: isis <isis at torproject.org>
> 
> 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 otf-active+unsubscribe at opentechfund.org.
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-reports/attachments/20160211/906099f3/attachment.sig>