I have been studying Tor and its related security issues recently, and have some questions.
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,
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,
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.
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.
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.
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.