Re: [tor-dev] design for a Tor router without anonymity compromises

[coderman <coderman@xxxxxxxxx>]

On 5/4/15, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:
> ...
> In my opinion, the most interesting use case for these devices is where
> Tor Launcher implements a peering mechanism whereby the user can click a
> button at some point in the initial connection wizard that says "My
> Router Knows My Tor Configuration."
>
> When this button is clicked, a TLS connection [.. with good auth ..] ...
>
> After this authentication step, Tor Launcher could obtain a set of
> bridge lines from the router via a simple JSON-RPC request, and then
> configure them as its bridges. The router enforces that these bridges
> (and only these bridges) can be connected to, or else a warning LED goes
> off.

great; this resolves the bridge and pluggable transport deficiency!
 and reduces the impact of Browser vulnerability, among other benefits.



> ... any public
> Guard node that has a DirPort can also be used as a bridge, so this
> configuration method need not be limited to censored users who perform
> such a configuration. In the uncensored case, the router could randomly
> select a Guard node for all users on the local network, which will also
> serve to reduce that local network's exposure to the Guard population,
> as well as reduce Guard-choice fingerprintability of the collection of
> devices on the local network.

great; this addresses my other concern with local users relying on
differing sets of guards among them, at the same time.



> The fact that the router is in control of the client configuration means
> that it serves as an additional security layer to protect against
> compromise of the browser. Since the browser and the rest of the
> end-user's computer have a much higher vulnerability surface that a
> router does, and are also much harder to audit for correctness than
> simply verifying a few bridge lines are as expected, this configuration
> direction is far superior than the browser automatically configuring the
> router. It also simplifies the user experience for setting up a whole
> group of people on a secure Tor network at once.

agreed; this would make the best configuration, the best user
experience, and more resilience against browser attacks.

thank you for the feedback!



> As I've said in the past, if someone is willing to deploy the router
> side of this protocol in an easy-to-use router formfactor, we would
> implement the corresponding part in Tor Launcher. This would cover
> Tails, Tor Browser, Tor Birdy, and Tor Messenger users right off the
> bat.

Tor Birdy is another i had not considered, and is absolutely worth
including, my own aversion to encrypted email aside...

as for the Tor Launcher coding, i'm holding you to that promise! :)

best regards, and thanks again,
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev