Re: [tor-dev] design for a Tor router without anonymity compromises
On 5/3/15, teor teor2...@gmail.com wrote: ... Some users will want as little logging as possible, as it can lead to privacy leaks if the device is compromised - may I suggest you turn it off by default? you are correct; the default should be no logging. i have updated the document, and noted that any logging requires explicit enable by owner. thank you! best regards, ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] design for a Tor router without anonymity compromises
On Sat, May 02, 2015 at 08:37:17PM -0700, coderman wrote: a friend and i are working on a Tor router design that doesn't compromise anonymity for convenience. [0][1][2][3][4] So, unlike a transparent tor router, this system is not intended to prevent malicious software on client computers from being able to learn the client computer's location, right? An attacker who has compromised some client software just needs to control a single relay in the consensus, and they'll be allowed to connect to it directly? It is unclear to me what exactly this kind of tor router *is* supposed to protect against. (I haven't read the whole document yet but I read a few sections including Threat Model and I'm confused.) ~leif ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] design for a Tor router without anonymity compromises
coderman: On 5/3/15, intrigeri intrig...@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 signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] working back to socks_request_t
Thanks for going into so much detail, you've given me a lot to think about. The real solution is probably the one that nobody wants to take on - having an application HTTP port that could take direct input from HTTP aware stuff and utilize a richer set of information then SOCKS allows for. I've spent a couple evenings looking to see if I could take the code stuff from the dirport and use it for that purpose. I need to spend another couple evenings and and go back and look at the SOCKS4 stuff, I've just recently realized that the state machine for that is closer to an http request/response. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] design for a Tor router without anonymity compromises
On 5/4/15, Leif Ryge l...@synthesize.us wrote: ... So, unlike a transparent tor router, this system is not intended to prevent malicious software on client computers from being able to learn the client computer's location, right? hello Leif! this deserves a longer answer, but you're right. if the attacker is using Tor itself a Tor enforcing gateway can't protect against those attacks. DNS leaks, UDP exfil (like the MAC leaking attacks), Flash based proxy bypass. these types of attacks can be stopped and warned about. a malicious relay, a malicious hidden services, at the network level a Tor enforcing router can't discriminate or help here. An attacker who has compromised some client software just needs to control a single relay in the consensus, and they'll be allowed to connect to it directly? you don't even need to control a relay, this could be performed via hidden service, as well. It is unclear to me what exactly this kind of tor router *is* supposed to protect against. (I haven't read the whole document yet but I read a few sections including Threat Model and I'm confused.) i will clarify to make this more apparent. best regards, ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
