Hacker News new | comments | show | ask | jobs | submit login
Most TOR servers are vulnerable (NSA crackable) (erratasec.com)
100 points by cklaus on Sept 7, 2013 | hide | past | web | favorite | 49 comments

Given the extent of the five eyes (NSA,GCHQ,DSD, etc) taping of major fiber lines, Tor is almost certainly useless against the NSA even without backdoors. The NSA doesn't need to resort to expensive key cracking operations to break either the anonymity or confidentiality of Tor. They just have to be able to see entry and exit node traffic.

From the original paper by the Tor developers:

"A global passive adversary is the most commonly assumed threat when analyzing theoretical anonymity designs. But like all practical low-latency systems, Tor does not protect against such a strong adversary." --- Tor: The Second-Generation Onion Router http://www.dtic.mil/dtic/tr/fulltext/u2/a465464.pdf

I wonder why the common assumption is that the NSA doesn't run Tor nodes. Why wouldn't they?

The NSA's (authorized) budget is $10.8 billion[1]. For $5 you can get a server with 20GB SSD and 1TB of transfer per month. It doesn't seem like it'd take very much money to be able to ensure that at least, say, 1% of Tor users' traffic passes through your entry and exit nodes, de-anonymizing them. So over a long enough time scale, that would de-anonymize quite a lot of interesting traffic, and interesting users.

One solution is VPN over Tor. But the NSA claims they've cracked 30 VPN providers, and are focused on cracking the rest as soon as possible. That's a lot of compromised VPN providers.

You could set up your own server and use that as a VPN, but if you pay with Bitcoin, then it's trivial to analyze the blockchain to tie your identity to the server, unless you use a tumbling service like bitcoinfog. But even if you manage to get a server set up anonymously, then what? You still would want to use VPN over Tor, since that's your best bet for privacy. But as soon as you get de-anonymized on Tor, that correlates your home IP address with your anonymous server, thus de-anonymizing your server too.

I can't think of any options to be truly safe from a global passive adversary that doesn't also cost >1MM to set up initially. Any ideas?

[1] http://www.washingtonpost.com/wp-srv/special/national/black-...

> I wonder why the common assumption is that the NSA doesn't run Tor nodes. Why wouldn't they?

Is that really a common assumption? I would expect that most people assume otherwise. Surely anybody informed knows that at least many, if not most, exit nodes are "hostile".

> unless you use a tumbling service like bitcoinfog

Which could be run by the NSA...

It's turtles all of the way down.

Connect to the Internet only through public WiFi hotspots. Run a sandboxed browser with all cookies deleted in each session or no cookies at all.

still can't avoid security cams + face recognition...

Every time elorant's comment subject crosses my mind, this comes up. How would we go about getting online anonymously using open wifi without worrying about cameras being planted everywhere?

Leave a raspberrypi hidden near an open wifi spot and connect into it and route traffic through it? That would still require us to connect to their network from another one...

Probably the best opsec for this would be to access the Wi-Fi from a location that is somewhat distant from the hotspot using a cantenna. Use a laptop that you purchased with cash at least a few months ago at a non-local thrift store (most thift stores won't archive video for more than a few weeks at most, if they even have cameras) and run off of a live CD like tails. Wear gloves while using the laptop and destroy and dispose of it immediately after use, preferably in a place where an old discarded laptop would not be suspicious.

Doing all of this will make you stand out more. Better to blend in with the general public a bit more.

Buy a cheap (preferably stolen) smartphone on craigslist and throw away the SIM card. Preferably this should be a phone with a removable battery. Walk to a bus stop that is near to a starbucks and jump onto their wifi with the phone, pretending to wait for the bus. After a while, walk away. Since you are outside during the entire process you can do this during winter and bundle up, concealing your identity while not looking suspicious.

Using a laptop at a busstop would draw attention. Using a cantenna anywhere not private would also draw attention. Getting a private place to use the cantenna is prone to problems (you could aim it out your apartment window, but that ties you to a location. You could park a van nearby, but that is suspicious). You can easily dispose of the smartphone later; just microwave it then go for a nature walk and throw it in the river.

Wear an Obama mask?

sunglasses will do. Just like that...

Sunglasses with infrared emitters. Blinds CCDs without visible light.

Well, many of us suspect a big percentage of Tor nodes are run by the NSA and it has been like that for many years. This isn't news...

Do you have a source for the claim that the NSA has cracked thirty VPN providers? The only source I've seen so far that makes any similar claim was the cryptome.org document for prosecutors which was a hoax.

http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet... ctrl-f VPN.

What is the cryptome document for prosectors that you refer to?

I now assume you mean this:



That's a pretty obvious hoax, detective "Stu Pitt" and "Laughlin Foo". It's good that it was quickly labelled as such.

Stop this "do you have evidence" lark. We are not talking scientific review or non US court here.

All people are doing is applying the same logic and standards governments and spy agencies do. Is there any evidence that the WHOLE of the US and rest of the planet's public are traitors and terrorists? No. But they could be, right? Best not take a chance, right? "We" can do it, it is possible, so "they might be doing it. And so on.

So, the NSA can or could compromise tor nodes, we know it is possible, so why take the risk? Especially if you are, say, Snowden or a freedom advocate.

They were just curious...

It's probably good to insist on sources. I should've provided one originally anyway: http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet...

Actually, there are...

1. VPNs using PPTP

2. VPNs using OpenVPN

1) should not be used anymore, it is more vulnerable by design (intercept the initial handshake and you're set; the NSA slides referred to a feature "Show VPN startups", which is probably what they meant by that).

So my guess is that when the say "we've cracked VPNs", it's probably PPTP VPNs, but then again, nobody knows for sure.

Run your own botnet. Illegal, anonymous, cheap and extremely effective. There's a reason both the NSA and the Chinese launch attacks via botnets. They hide the real actors behind a veil of zombies.

You can buy bitcoins for cash. Pay for a VPN with that.

Or pay VPN with cash. (Mullvad.net does it.)

So I'm totally making stuff up here, and my interest in crypto has a hackish rather than academic flavor, but...

Couldn't we design a system that doesn't fall in this scenario, by using a constant-rate packet-blasting network that emits "background radiation" even if nothing is happening, and then filters out the good stuff via chaffing/winnowing [1]? This would clog the tubes like a torrent and run you a similar tab, but wouldn't it be 100% anonymous even in the face of such an adversary, while still being low-latency?

[1] http://en.wikipedia.org/wiki/Chaffing_and_winnowing

I'm working on something along those lines at the moment - constant rate broadcast of GPG-encrypted messages -> https://github.com/shish/firehose

Freenet actually does this, though they aren't just sending random chaff, they'll actually use it to duplicate the data. It makes this particular attack impossible, but freenet has it's own potential issues. If you control all of someone's inputs and outputs you can still determine when they are using the system.

Yes, but Tor is already very slow, and it has a lot of resources behind it already. It would take a substantial amount of money to bootstrap your network. It'd be a worthy 1-10MM investment --- assuming you don't want any ROI on it.

I'm somewhat confused, exit nodes are not used when connecting to tor services, right? Only when you use tor to connect to the regular web.

"Of course, this is still just guessing about the NSA's capabilities. As it turns out, the newer Elliptical keys may turn out to be relatively easier to crack than people thought, meaning that the older software may in fact be more secure. But since 1024 bit RSA/DH has been the most popular SSL encryption for the past decade, I'd assume that it's that, rather than curves, that the NSA is best at cracking."

So it is suggested to update to a newer version that uses EC, but we are not sure if EC is not breakable? Others ([1], [2]) suggest that RSA is more secure than EC!?

I wish that the security experts could give "clear" advise.

EDIT: Added proper links to sources suggesting RSA over EC.

[1] Bruce Schneider in http://www.theguardian.com/world/2013/sep/05/nsa-how-to-rema...

"Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can."

[2] Fefe (it's in German) http://blog.fefe.de/?ts=acd52294

Regarding ECC, whenever a "constant" appears in a cryptographic algorithm, BEWARE.

Yes, I know about "nothing up my sleeve" numbers... However the ones used for ECC are not of this type.

What a sad state of affairs.

> However the ones used for ECC are not of this type.

Yes they are. The P-XXXr curves which are used by most of the ECC using web (and Tor, when it uses ECC) were generated by using a deterministic strongly pseudo-random procedure which you can repeat for yourself. See page 187 of FIPS 186-3.

Okay, I need to eat my words here.

I went to review the deterministic procedure because I wanted to see if I could reproduce the SECP256k1 curve we use in Bitcoin. They don't give a procedure for the Koblitz curves, but they have far less design freedom than the non-koblitz so I thought perhaps I'd stumble into it with the "most obvious" procedure.

The deterministic procedure basically computes SHA1 on some seed and uses it to assign the parameters then checks the curve order, etc.. wash rinse repeat.

Then I looked at the random seed values for the P-xxxr curves. For example, P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90.

_No_ justification is given for that value. The stated purpose of the "veritably random" procedure "ensures that the parameters cannot be predetermined. The parameters are therefore extremely unlikely to be susceptible to future special-purpose attacks, and no trapdoors can have been placed in the parameters during their generation".

Considering the stated purpose I would have expected the seed to be some small value like ... "6F" and for all smaller values to fail the test. Anything else would have suggested that they tested a large number of values, and thus the parameters could embody any undisclosed mathematical characteristic whos rareness is only bounded by how many times they could run sha1 and test.

I now personally consider this to be smoking evidence that the parameters are cooked. Maybe they were only cooked in ways that make them stronger? Maybe????

SECG also makes a somewhat curious remark:

"The elliptic curve domain parameters over (primes) supplied at each security level typically consist of examples of two different types of parameters — one type being parameters associated with a Koblitz curve and the other type being parameters chosen verifiably at random — although only verifiably random parameters are supplied at export strength and at extremely high strength."

The fact that only "verifiably random" are given for export strength would seem to make more sense if you cynically read "verifiably random" as "backdoored to all heck". (though it could be more innocently explained that the performance improvements of Koblitz wasn't so important there, and/or they considered those curves weak enough to not bother with the extra effort required to produce the Koblitz curves).

You consider it smoking evidence of "cooked" parameters that he hashed a random string?

This is the technique suggested by all of IEEE-1363 2000, and in every place its suggested, the standard is at pains to suggest that it provides only a degree of assurance; the standard authors go as far as to repeat the exact same text in each location (RSA, DSA, ECC, &c) while customizing the "what could go wrong" part of the paragraph.

1363 predates the NIST curves, for whatever that's worth.

It leaves the specifier of the parameters free to pick ones subject to arbitrary non-disclosed criteria, subject to the limitation that criteria happen frequently enough relative to how many times he can afford to run SHA1.

E.g. If he can afford to run SHA1 2^32 times as part of preparing a curve, he can pick curves that have non-disclosed strengthening or weakening factors which tend to be found at random 1:2^32 times or more often.

Basically it shows that the parameters are random subject to a computationally bounded attacker. But the bound is unrealistic: They're only random if the attacker tries only once. As the attacker tries multiple times, he gains selection over the parameters proportional to his effort.

E.g. he could pick curves that have twists with particular structure, or which are have pairings to extension fields which he could solve the discrete log problem in. (This is only mostly speculative: Certainly there are weak curves which occur with this frequency, the procedure itself directly excludes one type: supersingular curves. If we didn't know that the DLP problem was trivial over super-singular curves then this exact procedure could have selected for them or excluded them without revealing that the selecting party was doing anything non-public.)

This wouldn't be alarming to me except for how trivial it would be to provide a higher level of assurance in exactly the same framework: Start with an initial sleeve provably specified after the framework with no control over it, and increment it one at a time and take the first set of parameters that pass. Failing that, a very low entropy set of parameters (like starting at zero and incrementing) would produce good evidence that the parameter selecting party wasn't selecting based on hidden characteristics.

I note that the brainpool curves (http://tools.ietf.org/html/rfc5639) come much closer what I'd expected had been done here.

I am now rather confused in my ignorance... So the parameters (for ECC) were chosen "at random" theoretically (and so here lies the trust inherent to these?). Thanks for the info.

The parameters are derived from the SHA1 of high entropy values of unspecified origin.

It means they very very likely couldn't have algebraically produced a single set of specific magic evil values that enabled them to crack the cryptosystem, a true backdoor, since it would have been computationally infeasible to get SHA1 to output the right values.

However, they could have tried billions and billions of sha1 seeds looking for parameters which met some unknown to us characteristics which made the parameters stronger or weaker. Their "veritably random" procedure could have easily foreclosed this possibility, as was later done for some different parameter sets, but they did not.

So that's true, but remember that they're simply employing the process that IEEE 1363 described years earlier. The circumstances are different: IEEE was trying to explain how to generate parameters, and NIST was specifying which parameters to use, but the methodology is the same.

It is thus not particularly "telling" that there's an opaque SHA-1 seed. That is to say, it's not a "tell" that they didn't use a simple string (like the digits of pi or something), because that's not the IEEE method.

I preemptively agree that we'd have been better off had the seed been transparently generated, too.

I see, thanks for the explanation.

Thank you very much for going into such detail. But what does it mean for the ECC or RSA methods? Which can be considered as secure? I guess we need more expertise, right?

There is no specific reason to believe ECC methods on these standard curves (or other well selected parameters) to be insecure.

But at the same time if someone argues that the NSA could have influenced the parameters to create hidden weaknesses predicated on math unknown to the public, that argument can't be denied. It might even be supported on the basis that they could have easily closed off that argument but did not. (OTOH, equally I could argue that the same selection may have been used to make it stronger).

As far as RSA goes, their usage involves fewer free parameters... but to get RSA up to the security levels people are demanding today require increasingly large and slow keys. If the crypto is too burdensome it'll get avoided, and thats worse than whatever speculation you might have about NSA weakening of EC systems.

Ab, OK, my bad. Thanks for the pointer and sorry for the mistake.

2.3.25 is the current stable version. 2.4.* is in development. Tor server operators would have to compile from source or use the upstream deb/rpm repos.


Debian/Ubuntu isn't alone in this. It should be noted that the majority of nodes are using Linux and of those, the 0.2.4 package is still not available unless you're running some flavor of "untested" or other bleeding edge distro.

Of course that doesn't stop operators from simply downloading the latest package themselves from the Tor project or compiling from source.

Of course, this is still just guessing about the NSA's capabilities. As it turns out, the newer Elliptical keys may turn out to be relatively easier to crack than people thought, meaning that the older software may in fact be more secure.

Wait, what?

So why isn't the repo up to date?

I honestly don't know the answer as I don't deal with Linux repo's much

Because 2.4 is still marked as alpha. Versions on the torproject download page, their repo and Ubuntu repo all match.

    % wajig policy tor
      Version table:
     *** 0
            500 http://ua.archive.ubuntu.com/ubuntu/ raring/universe amd64 Packages
            100 /var/lib/dpkg/status 0
            500 http://deb.torproject.org/torproject.org/ raring/main amd64 Packages

Depends on the distro and the version.

I don't see how ECDHE has any effect on the (in)security mentioned in the article. It clearly states that the RSA keys being only 1024 bits is the problem. How does using ECDHE-RSA change this?

Why is ECDHE+3DES a "lulz-worthy combination"?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact