On 5/4/15, Mike Perry mikeperry@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,