Comment by jerf | Hacker News Reader

Comment by jerf | Hacker News Reader

Parent Full thread

"How much are you willing to bet they can't decrypt https?"

I'd bet quite a bit, though not "my life", that they do not have a generalized "read everything" ability for all forms of SSL. They may have what cryptographers would call "a crack", but that's a low bar, and doesn't prove they have a practical attack.

However, DDG is currently using 128-bit RC4, which is very weak. [1] I wouldn't care to bet anything that the NSA doesn't have an RC4 cipher crack that is practical to run on wide swathes of traffic.

RC4 is very popular, which I believe is because some people claimed it was a defense against the BEAST attack. I researched this for work, and I couldn't find anyone whom I trusted saying that was a good mitigation. The people I trusted merely observed that RC4 was not vulnerable, but never said you should switch to it. Only secondary sources ever suggested that. My conclusion was that there was a reason for the primary sources never suggesting that; in response to a theoretical break of the rest of SSL, the correct move was not to move to a solution that had much more practical attacks already known than what BEAST demonstrated. But now it's even sillier; BEAST has been either entirely or almost entirely mitigated in browsers (there's no server-side defense against BEAST, but there's a client-side one you can use, and browsers now have it). As far as I can tell, RC4 should be abandoned and we should resume using stronger ciphers for SSL. Anyone still concerned about BEAST should update their browser.

[1]: http://nakedsecurity.sophos.com/2013/03/16/has-https-finally...

OTOH, if they can get a CA - any CA - to cooperate, they can MITM anyone without having to break SSL.

Only for targeted traffic though. They can't record, go back, and break it.

Not without someone noticing. Some sites have pinned certs in Chrome, which would stop this, and even without that you would expect some knowledgeable techie at Facebook or Github or something to be using their home laptop and say, "Wait a sec, this isn't my company's public cert!"

Not having seen any blog posts screaming, "OMG, my site is being hijacked wholesale," I can only assume that the NSA isn't doing this (or has managed to squelch by legal order every single person privy to the real cert at MITM'ed sites, which is absurd and would beg the question, why not obtain the private key from these people in a similar way?).

Could they do this selectively, and only MITM people on watchlists?

They have to set up impersonating SSL certs for every connection they want to MITM. While there'd clearly be value in them inserting or subverting network hops between "the great unwashed" and gmail/facebook/aim servers, there's very little chance the NSA have access to hops along the path between my (Australian) adsl connection and my vps (located in Australia).

For internal (or routed through) US traffic - while Verizon's lack of interest in protecting customer data is probably shared by major backbone providers - I _strongly_ doubt even the NSA has enough gear hanging off backbones to actively MITM any significant proportion of the firehose that'd represent. Even the AT&T "secret room" probably doesn't house enough gear to be able to create fake(signed)certs and MITM every SSL connection for millions or more simultaneous users browsing every https site under the sun.

Having said that, I'd bet good money the _do_ target specific SSL traffic - has anyone checked the SSL connections to TOR entry and exit points recently? That'd be one spectacularly obvious path to try "speculative MITM attacks".

This is why I tell people that actual fingerprint check is much better than any CA.

Yes, but how do you get the fingerprint to check against?

I assume he also implies that fingerprints aren't any safer

Who?

The EFF's "HTTPS Everywhere" extension is a great place to start.

    https://www.eff.org/https-everywhere

Do they need to MITM? If they have a copy of the private key, can't they just use it to decrypt the data .. even old data for which they've only just acquired the key?

Having the root CA's private key doesn't give them access to the end entity's private keys. When you ask a CA for a cert, you only provide them with your public key (in the form of a CSR) for them to sign. The CSR does not contain the private key.

But getting an employee to hand over the private key and giving him a gag order afterwards is an option of course.

True, but they would have to do this for every single web server they would want to collect information from. Not impossible, but it'd be a lot of work.

https://en.wikipedia.org/wiki/Perfect_forward_secrecy

https://en.wikipedia.org/wiki/ECDHE

Google is using it, a few other sites, too, though they are in the minority. OpenSSL supports it since version 1.0.0 that was released in March 2010.

to your latter question: no, not with the right ciphers.

http://en.wikipedia.org/wiki/Perfect_forward_secrecy

Perfect forward secrecy doesn't apply if the NSA has broken the key exchange algorithm and has your session keys.

Thanks for pointing this out. I'm looking into updating our ciphers very soon.

Heh, I was wondering if that might get noticed. :)

On the one hand, don't take my word for it; I also have not found anyone I trust who has verified my explanation directly. On the other hand, I did do my best to read the primary sources very carefully, both for what they say and what they don't say, and I was confident enough to implement more conventionally strong ciphers on the services I'm responsible for, so my money is where my metaphorical mouth is.

I might bet my life on HTTPS depending on what my alternate choices are. I'm loathe to bet my life on anything, though.

Thanks for the link, that was an awesome article. Well written and technically substantial. How did you come across it?

I googled for something like "rc4 weak crack" or something like that. I was just trying to substantiate the claim that RC4 is weak.

Reply on news.ycombinator.com