Two months after FBI debacle, Tor Project still can’t get an answer from CMU
arstechnica.com
arstechnica.com
This is kind of worrying. I hope the Tor Project has information on the attack is looking into ways to mitigate this. But if it's due to the protocol nature, then maybe it's time to look for a successor (we aren't using WEP anymore, right?)
As to the CMU stuff... Tokyo University has this pledge to make sure basically no military research is done on campus, which I feel to be pretty laudable.
I wonder if there's a similarly worded pledge for this sort of thing. But at the same time, universities can do a lot of good security research that can, in the end, strengthen the systems we use.
The "$1 million to target these specific people" sounds dirty, but "$1 million to do research on the vulnerabilities of Tor"... well that sounds like research to me. Pretty tricky.
[0] https://blog.torproject.org/blog/tor-security-advisory-relay...
So, you move it off-campus. See e.g. the MIT Lincoln Lab, https://www.ll.mit.edu/
I think a wholesale ban on military research is pretty silly; the ethical implications of projects should be considered on a case by case basis by the university.
How's that work during Vietnam when the DoD dangled bags of money in front of universities?
To use a more modern analogy that exists on the internet, the 2010 US military research / development / testing budget looks like it was around USD$80b.
Or in other terms, roughly equal to the total of all research spending by all other branches of the US government. (http://www.aaas.org/sites/default/files/RDGDP_1.jpg)
Now you're a university professor / dean / president. Times are hard (they always are, you're in academia). There's a huge pie sitting right next to the one you've been fighting over, and all you have to do is work on certain technologies that may or may not have lethal consequences.
I wouldn't take the bet on many people saying "No thanks, I'll be happy giving up grant money for moral reasons."
People needing a high level of protection can use and should use Tor in their workflow but they should not expect a one-click solution. On the other hand, it's perfectly adequate for day to day use of privacy minded individuals that are not targeted by active attacks.
The attacks on Tor are largely in the form of:
A) Outright implementation flaws [e.g. Software bugs ]
B) Malicious actors deploying Tor nodes [e.g. On July 4 2014 we found a group of relays that we assume were trying to deanonymize users. They appear to have been targeting people who operate or access Tor hidden services. The attack involved modifying Tor protocol headers to do traffic confirmation attacks. https://blog.torproject.org/blog/tor-security-advisory-relay... ]
> A traffic confirmation attack is possible when the attacker controls or observes the relays on both ends of a Tor circuit and then compares traffic timing, volume, or other characteristics to conclude that the two relays are indeed on the same circuit. If the first relay in the circuit (called the "entry guard") knows the IP address of the user, and the last relay in the circuit knows the resource or destination she is accessing, then together they can deanonymize her. You can read more about traffic confirmation attacks, including pointers to many research papers, at this blog post from 2009:
Pretty much the only defense is to control the entry nodes you use yourself by:
https://www.torproject.org/docs/faq.html.en#EntryGuards
> Restricting your entry nodes may also help against attackers who want to run a few Tor nodes and easily enumerate all of the Tor user IP addresses. (Even though they can't learn what destinations the users are talking to, they still might be able to do bad things with just a list of users.) However, that feature won't really become useful until we move to a "directory guard" design as well.
Its an inherent problem with a low latency anonymity network that is really an open research problem.
However, controlling your entry nodes has a different problem:
1) It pretty clearly links you to you entering the tor network via a consistent sent of nodes.
2) Capturing these nodes via the DC and warrants/legal action has been done in the past. As any is going to be able to find these nodes since they are no longer randomly selected...
3) Once you are actively targeted you are just as vulnerable.
It is always interesting to see what they say there. Because if they know, for example, one type of crypto technique or implementation is vulnerable will they still recommend it for TS classified material storage? Will they recommend for US military or diplomatic service? If they don't, it might leave that open to attack, and they are not doing their job. If they do say "don't use this combination of AES, prime numbers, or OpenSSL implementations", that also gives something away.
I wonder if people people who make these recommendations even talk to people who discover, exploit, and actively penetrate systems? Because everything is very compartmentalized, they actually might not be able to.
That is why they are probably very interested (like we saw) in somehow subverting or weakening some algorithms and implementation so they are the only ones that have a key (Dual_EC_DRBG) , or they are the only ones that potentially have a computational capacity to exploit (DES).
In either case, I feel information assurance and signals intelligence arms really should never have been the same agency: they are roles entirely at odds with each other and do not seem to even have their own governments' equities properly balanced, nor their recommendations always having been given in good faith. So be cautious drawing any conclusions from their advice.
Unfortunately, that is not the sort of 'reform' that either government is interested in, particularly my own. It's quite depressing, really.
That actually makes sense because of the way it was backdoor-ed. What they did there is the golden standard of subverting and backdoor-ing a crypto algorithm: go through a standards body, backdoor-ed it by using a public-private key. They hold the private key. Encourage others to use the system as much as they can (which includes showing the world that they themselves use it).
NSA have been having dreams of key escrow forever. It seems since the 90s, that dream was further and further from reality. But they didn't completely give it up. Dual_EC_DRBG was effectively becoming that key escrow they wanted for all the system that used it and they got to keep the private key and thus have a high enough assurance others won't use their backdoor.
Whoever was in charge of that operation, was probably patting themselves on the back every morning after waking up.
1) For security, most systems rely on their obscurity and on the fact that the assets they protect probably aren't worth much investment by the attackers. Tor can't rely on either of those circumstances: It's prominent and breaking into it is a one-stop solution to attacking many valuable targets.
2) Many organizations with large amounts of resources, from state intelligence agencies to law enforcement to security vendors to ISPs, would like to find solutions to hacking Tor security inexpensively.
3) True security is very difficult and expensive. For Tor, this is taken to an extreme by #2. Does the Tor Project have the resources to implement bug-free software (e.g., the kind that flies passsenger planes)? Certainly not. Can they find and fix bugs as quickly as the attackers described above find and exploit them? Certainly not. I'm not criticizing them; they just don't have the resources.
4) Assuming the underlying concept of onion routing is secure, there still are plenty of targets for attacks such as implementation and all the other code Tor relies on (e.g., almost all of Firefox for the Tor Browser, encryption algorithms, your OS, etc.). Attacking a Tor user doesn't seem impossible.
Based only on the theorizing above, and not knowing about Tor's actual implemenation, I fear that we're lucky if Tor still is expensive to attack. Of course, any smart attacker with an exploit will publicly complain how hard Tor is to hack.
Each time you use tor your packets actually go through a path of 3 different servers (or relays). If the attacker owns the two ends it's game over. How many relays are there out there? How many are owned by the NSA or other gov?
It's pretty obvious that this system just cannot work because a majority of relays are owned by the attacker.
But it looks like they put themselves in that position. Either by voluntary working with the FBI and allegedly taking a $1M grant, and/or doing unethical research by doing it on the live network.
(I mean, I guess it's possible for an NSL to order you to do anything, because America.)
What's worse - that CMU did this in the first place or that they did it so cheaply?
It can only require you to turn over existing records/information.
Yes they do. From their website:
"The Software Engineering Institute (SEI) is a not-for-profit Federally Funded Research and Development Center (FFRDC) at Carnegie Mellon University, specifically established by the U.S. Department of Defense (DoD) to focus on software and cybersecurity."
On one hand, leading academic institutions are commonly understood to have a responsibility to preserve free speech (especially speech that is critical of military or government action), remain as a neutral education and research body decoupled from any specific political or military agendas, and help lead in social progress towards greater overall ethical standards in education, research, and scholarship.
On the other hand, many universities loan out the credential and status of being affiliated with them as a recruitment tactic to assist the DoD in the task of creating a diversified set of military research organizations, which from a superficial observation point of view (the view taken by many of the younger engineers duped into working for below market pay at such places) look like run-of-the-mill software/science/engineering jobs while having all sorts of ethical gray areas, and the end result is to create rampant ethical conflicts of interest, questionable management practices, and many other problems.
I don't think it's as simple as just pointing out that SEI is an FFRDC and moving on. The fact that universities in general continue to perpetuate this problem -- academia-military pseudo-credible research facility affiliation and status-mongering -- that is the bigger issue.
1.) Custom Firefox 'Browser Bundles' which do not auto-update and ensure latent vulnerabilities are left un-addressed
2.) Trusted 'Third Parties' running exit nodes who we hope and pray are doing their job correctly
3.) Weird and non-innocuous looking domains on the wire that do nothing more than alert the neighborhood that somebody's using TOR (Unless everyone's using it you stand out like a sore thumb)
4.) Sybil attacks in the form of people-with-more-money-than-you polluting the network
5.) ???
6.) Any number of other issues (which have since been patched in the past), but still work if the TOR user is uneducated about how TOR works (traffic analysis / correlation attacks / zero-knowledge-proof attacks, etc)
YouTube has been working for me using Tor Browser for months, if not years.
CMU[http://www.cmu.edu/] SEI[http://www.sei.cmu.edu/] CERT Division
[CERT logo] [SEI logo] [CMU Logo]
The first words on www.sei.cmu.edu are
CMU SEI CERT Division
[SEI logo] [CMU Logo]
CMU is clearly endorsing the actions of CERT.
That would be pretty cool, since anyone could prove source correctness automatically.
Tor has failed its users because the idea of running a public Tor cloud with volunteer entry, onion, and exit nodes is ludicrous. It means that the entire network is under surveillance all the time, the exact opposite of what you want. There has been widespread confirmation that the data you transfer via the public Tor cloud is being passively surveilled at the endpoints and actively modified when you, for example, download software. This makes it incredibly dangerous to use, likely more dangerous than just using the regular internet.
There are many other problems (like the fact that .onion sites are a dirty hack and likely have many undiscovered weaknesses like the ones CMU found) but nearly all of them are either deployment or architectural issues, not code security issues.
Like you said, Tor has architectural issues. Tor would be fine if it were low-profile, but it's not, and that's a major part of why the architecture is breaking down - it doesn't scale well with increasing users/publicity/nation-state-interest.
For example, side channel attacks. A classic attack on computerized cryptography. I don't know of any proof language that can protect against side channel attacks.
If you look online there are a few lists of tor attacks. The attacks include: snooping on exit relays, application issues, traffic correlation, website fingerprinting, congestion attacks, blocking tor access (declining to extend). Most of these are issues in the design of the tor system, not something I think source code proof systems are capable of preventing.