On 5/4/15, Mike Perry <mikepe...@torproject.org> 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
