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

[Mike Perry]

coderman:
> On 5/3/15, intrigeri <intrigeri at boum.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150504/1d2f650f/attachment.sig>