Additional Tor security at the client's network perimeter

Question

I have been studying Tor and its related security issues recently, and have some questions.

1. Aren't the most effective recent attacks on Tor, actually attacks on the browser (or plugins), rather than the Tor network itself? My understanding is that the recent exploits involve a script or malware forcing the user to make a direct connection outside of Tor, using his or her own IP address. Following this,

2. Couldn't these attacks be prevented by using a packet filter at the network perimeter? In other words, whitelist the Directory Authorities and the entry node, and block everything else at the client's network perimeter. I've tried getting Tor to operate this way and it seems functional, once the TBB loads the relay list and makes an initial connection. If I enable the filter before starting Tor, however, then the relay list doesn't populate (Vidalia), and the connection doesn't initiate. Finally,

3. Is there a way to configure Tor such that it will operate automatically upon startup through a packet filter like this, without having to temporarily disable the filter to get it started?

Something like this wouldn't defend against end-to-end timing correlation attacks, but my questions concern security on the client's end of the network.

Edit (09_15_2016):

1. Yes, I understand that the network itself is going to be a weak point that can't be solved by a security appliance at the client's end of the network. I have tremendous respect for our friends at the 3-letter acronym agencies, and have no sympathy for the people snared in the described sting operations. At the same time, I'm concerned that the attack was too easy. I believe that uncovering a user's identity should be costly enough in resources and effort that it will cause law enforcement to think twice before attempting it. It shouldn't be a trivial operation that can be carried out on large numbers of people on a whim.

2. I'm reading this carefully to make sure that I understand. Yes, I see now that I overlooked the obvious direct connection between the client and the directory authorities. Good catch. If traffic to any one of them could be viewed, then the connection itself could be used by malware to encode information, revealing the client's IP address. I've used Tor before with only one directory authority white-listed. In this case, I suppose the malware would have to signal to all nine DA servers, and the attacker would have to hope that the server(s) they could see would be the one(s) that is(are) white-listed. The direct connection to a DA server is a weakness, since there are only 9 of them, they are well-known, and hard-coded into Tor.

Here's a follow-up question for you: After loading the relay list on startup, is it possible to block access to all the DA servers? Would this prevent Tor from building new connections properly? Unfortunately I can't test this right now (haven't gotten approval from IT to run Tor yet). If it works, then this would force such possible malware to try other means for signaling. It could try identifying the guard node from within the system (if the compromised system is the same one running Tor or handling the network connection) and then exfiltrating this information and compromising the server's connection as before; or alternately by signaling to all guard nodes, with the attacker hoping that he's monitoring the one that happens to be white-listed (there are a lot more guard nodes than DA servers). Am I missing anything in this scenario?

In the interest of disclosure, we (at work) are looking into what we can offer the Tor community. I'm doing some initial background research to see if we can justify putting internal funding towards it. Initially the thought is to start at the client network perimeter with a hardened packet filter, then progress inward incrementally towards a stripped down and custom hardened OS. Obviously I still have a lot to learn.

Edit (09_15_16):

I think you're judging me too harshly. I wouldn't be entertaining this project if I liked the way things were being done. If everyone who accessed Freedom Hosting was filtering their network connections like we're discussing, then probably none of them would've had their IP addresses snagged, even with an outdated TBB...on Windows no less. At the same time, Tor is about freedom of speech and association to me, not the freedom to trade dirty pictures of children. I don't like to discuss this, and I really wish I knew better examples of a Tor user's local network or system (not the Tor network as a whole necessarily) being compromised that didn't involve these indefensible scenarios. Any ideas? Both you and I know that the same types of attacks can (and will) be used in the future, but against journalists, people with unpopular opinions, people who generally desire privacy, government agents themselves, and so on. I'm trying to prevent current exploits, and even ones that haven't been discovered yet. I can't go to upper management with Freedom Hosting as an example, though. I'd feel personally nauseated doing that, and I'd get some strange looks anyway.

Anyway, I'm going to try Tor on my home system to do some testing. I'll be using the access control list on my firewall router as the packet filter. I moved out to the boonies, and only have limited broadband wireless on a hotspot. However, I can run Tor on computer #1, connect to computer #2 through the router, and then route the traffic through computer #2 to the wireless interface. At least I hope I can do that... I wouldn't recommend that setup for anything other than testing, since it's not very secure.

Answer 1

1. There are exceptions like the CMU snitch attack where they did stunt hacking to seem cool infront of their hacker friends and in the process sold out a bunch of people out to law enforcment agencies around the world, which was an attack on the network itself. Other common vectors though are things like misconfiguration (people allowing flash) or user error (people doxing themselves). There are about 2 known cases of exploitation of the browser directly, Freedom Hosting which, when first discovered was already patched and Playpen which was probably 0day but we don't know for certain.

2. No. I know it's tempting to imagine it's the case and it is helpful, it's useful to have defense in-depth but imagine I'm some adversary in a hypothetical scenario where I can ignore any legal protections, or they can be wrangled around or I can make the case that they should be waived. Now I manage to compromise your browser with some exploit, I can execute code in the context of your user. You're using a packet filter that stops me connecting to anything except the Tor network. Your first problem is I can still steal all your documents and do anything that the user running the browser can even if I can't leave the network directly, I can still exfiltrate the data over Tor. It doesn't stop me from stealing any potentially personally identifying information that I can find after I've exploited you (e.g. hardware serial numbers and identifiers and personal documents). The second problem is that I can still connect to the entry guard and I can still connect to the directory authorities. This leaves a covert signalling channel, if I can make arbitrary connections to them I can signal to one of my reachable endpoints information, lets say an unique identifier attached to the exploit. If I was able to coerce or compromise the upstream ISP of one of the dirauths, I could watch for this signal and read the covert channel, exfiltrate the data over Tor itself and match it to which payload was dropped. I'd still have all the data I have, your real IP, your MAC address and where the payload was deployed from (e.g. what you were doing).

3. There are better approaches, namely enforcing Tor outside of the reach of the user that the browser is running is. This can be achieved by running Tor as a distinct user, allowing that user to connect to the internet and then only allowing the user that the browser runs as to connect to the tor instance, never any external connections. This way if someone attacks the browser (or other application the user is using over Tor) they won't be able to make a direct connection, this means they can't reveal the real IP address of the user to some external observer (problem two in item 2 above). This also works around some of the other problems that haven't been touched on yet, like the fallback directory servers that are a new feature (its not just dirauths you might fetch from) or unexpectedly breaking your connectivity and having to reconfigure your packet filter when you rotate guards. This can be achieved locally as in Tails or Subgraph or through an upstream tor enforcing proxy by using something like PORTAL, Whonix or Qubes TorAppVM. Note that this still doesn't solve problem one of item 2, I can still exfiltrate data over Tor so if the browser can access potentially personally identifying data then you might still have a bad day.

tl;dr packet filters aren't a panacea but they can break some attacks and are generally a good idea as part of a layered defence.

4. (Follow-up) In theory yes, note that in 3 I touched on the issue of fallback directory servers, these are a new idea to take some of the load off of directory authorities, these too may need to be allowed in your network policy. The only time you'd need to make those direct connections to authorities is during the initial bootstrapping to learn about the rest of the network (potentially if you'd been offline for a while and had a very stale consensus document? unsure on this one), once you have the rest of the network you can use other (non-authoritative) directory servers to fetch updates to the consensus. This disperses the load. An except to this (that might interest you) is the use of bridges. Since a censor can know and easily block direct connections to the directory authorities during the initial bootstrap of a Tor client, bridge connections use a concept of directory guards, essentially using the bridge as an initial hop onto the network. Using a bridge would mean that you'd only ever need to allow connections out to a single IP/Port (for the duration of the bridges lifetime). You may then have to take on the task of potentially rotating your "guard" bridge (guard rotation is a big topic in itself), if required.

For the record, I have no respect for the three letter agencies and many of the people caught up in the "stings" had done nothing wrong or illegal. Freedom Hosting may have been hosting content that was illegal but not all of their services were illegal and users of the services had no way of knowing that other services hosted at the same place their service was were illegal. Guilt by association is bullshit, by that line of moral weaselwording we should charge the entire Secret Service and the DEA for the greed and corruption of Mark Force and Shaun Bridges (and possibly other conspirators). And the CMU attack, attacked everyone indiscriminately. Your resting your laurels that it's okay because they caught "bad people" in the "sting" as a justification of it and not being something you should be concerned about as a way of enforcing law is clearly misguided. To invoke Godwin's Law, I'm sure some of the people killed during the Holocaust were legitimately bad people too. EOF.

P.S. Using the "child abuse" argument is throwing stones from a glass house.