coderman: > On 5/3/15, intrigeri <intrigeri@xxxxxxxx> wrote: > > ... > > Just to clarify, the threat model explicitly doesn't include "Attacker > > is able to reconfigure Tor on a client system to use an arbitrary set > > of bridges", right? > > correct. > > neither bridges nor pluggable transports are supported. i have added a > FAQ entry for this. thanks! > > in the future, it would be useful to have a way to securely distribute > bridges or obfuscated proxies to trusted user on the local network. > however, this is not a trivial task, and you'd want to avoid > compromising all of your bridges at once if a failure occurs. > > > last but not least, if your attacker is coordinating the attack over > Tor, obviously this cannot be thwarted at the local network level by a > Tor router device. host security is critical, even with a Tor > enforcing router as backup. that's a longer subject i need to think > about more before writing anything useful. Well, there is a way to restrict the capabilities of such an adversary quite severely. 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 can be made to the router IP, either through DNS discovery or by simply looking up the current gateway IP. Tor Launcher could then present the user with a randomart or randomwords representation of the TLS fingerprint of the router for confirmation that they are connecting to the expected device. 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. While in the future it would be nice if the router could be configured with arbitrary PT bridge lines, it actually turns out that 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. 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. 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. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev