Hacker News Reader

Comment by w1ntermute | Hacker News Reader

Can someone who actually knows about encryption comment on whether it's actually physically feasible for the NSA to have actually broken, say, SSL 3.0 (which has 128 bits of entropy, IIRC) on a large scale (i.e., when you're sifting through petabytes of data on a daily basis)?

And if this were really an issue, couldn't you just use 4096-bit RSA (unless they have managed to surreptitiously insert a backdoor in it)?

View on HN

Brute force is only required if there isn't a vulnerability (either in the algorithm or that the NSA has a key).

> Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.”

> N.S.A. documents show that the agency maintains an internal database of encryption keys for specific commercial products, called a Key Provisioning Service, which can automatically decode many messages. If the necessary key is not in the collection, a request goes to the separate Key Recovery Service, which tries to obtain it.

Neither of those apply to SSL 3.0, do they?

Well, it's not that simple, is it? Generally speaking, the public key algorithm used in SSL is used to protect the private key that is used to protect the data:

1) Site sends public key certificate to browser. 2) Browser verifies certificate against in-browser store. 3) Browser extracts public key from certificate. 4) Browser generates symmetric/private key. 5) Browser encrypts that symmetric key with the site's public key. 6) Browser sends encrypted symmetric key to site. 7) Site decrypts symmetric key with its private key (the one associated with its public key certificate) 8) Site and browser encrypt and decrypt data using the privately shared symmetric key.

If I break the public key algorithm(s) used in SSL, I break all of that. But we think that's tough (as in NP hard).

If I break SSL itself (find flaws in negotiation, etc.) I might be able to break all of that. That's been done a few times (SSL v1.0 is garbage; v2.0 is borked; v3.0 a little broken; only TLS 1.2 is borkless, so far. As far as we know.

If I break the symmetric algorithm(s), then I can get at the data without breaking SSL itself. But we think that's tough, too. As far as we know.

If any of the software used in any of the above is borked, then usable attack vectors may be exist. Or not. We don't know until we find them.

It's a complex box of moving parts with many potential attack vectors, many potential vulnerabilities, etc.

Who really knows if the NSA might have found a multi-vector, multi-vulnerability attack that allows them to get at a lot of encrypted data without having broken all of any one of those things.

It's purest speculation until someone with a sufficient clearance and sufficient need-to-know decides to speak out, and even then it would remain unconfirmed.

SSL relies on a chain of trust, and it's prudent to assume that the NSA has the private keys necessary to produce valid certificates that will be accepted by the certificates that ship with Windows, OS X, Firefox, etc out of the box.

So man-in-the-middle attacks are certainly within their capability and fairly hard to detect. As to whether the NSA can passively intercept and decrypt SSL traffic, I don't know, but they may not need to.

How are they hard to detect? Wouldn't solutions like certificate pinning prevent this?

Yes, certificate pinning would alert the user to a MITM attack, but it's not commonly used. By "hard to detect", I meant that it's impossible to see simply by examining the certificate if it's genuine, you can only detect when the certificate changes. And since SSL certs expire and are re-issued all the time, it makes it a fairly large headache to continually try and guess whether the other party changed their own cert or if you are experiencing a MITM attack.

Isn't it considered best practice, especially for situations where you can control the client - i.e. banking apps on your phone?

You want to use something like TLSpool (http://www.tlspool.org) and DANE. For a browser something like Firefox's Certificate Patrol is a great solution.

It looks like there's no chance for even the slightest expectation of privacy. Even if the data is encrypted they can ask American companies to decrypt it, after all they store the encryption keys. Even if the encryption keys are stored on the client side, they can push fake updates through major browsers or straight out compel American companies to insert backdoors in their software (e.g. Google Chrome) and get access to those keys. Our reliance on these services is what most likely would need to be avoided in the pursuit of privacy, but could you live without Google Search, Google Maps, GMail, Outlook, and on and on?

Your self-signed 4096-bit key is probably fine. Even better, be your own CA.

People assume CAs should be trusted but it's a huge game of chicken: If the NSA can't break SSL, you have to assume that either SSL is opaque to them, which these revelations seem to contradict, or they have corrupted the CAs.

Or that SSL is irrelevant because they've tapped whatever service you're connecting to.

This is all theoretical, but you could use decentralized services/protocols that would eliminate such an opportunity.

If I was in the NSA (which I am not) I would place a backdoor in the browser themselves, and since the browsers auto-update from the internet anyway, I would change the DNS provider for the machine being watched (remember the DNS settings generally default to that provided by your ISP) to point to the NSA-version of the browser, and then the user would be browsing securely, but after decryption and before display, the payload would be sent elsewhere to be collected.

I don't think this would be particulary hard either. For IE, the NSA can just get MSFT to do it. For Firefox, they can compile from source, and for Chrome, well, they can probably compile from source too, because they probably have access to the build source of Chrome, with or without GOOG mgmt knowledge.

Can anyone come up with a (technical) reason the NSA could not be doing this?

Browsers auto-update over SSL and hopefully use certificate pinning.

Your machine would be showing an extra outbound connection.

Very few people have any idea how many outbound connections their machine opens or which software is opening them. There seems to be just enough people paying attention to this that it would be caught but most people would never know.

For a specific target? Sure, why not.

But if they did that to everyone? Surely it would be noticed. Probably very quickly. There are a LOT of smart security researchers scouring browsers for bugs and running them in carefully controlled environments every day. Someone would also eventually notice that the production binary doesn't match the version built from source, especially for open-source browsers.

It might be but it is highly dubious. However, they MIGHT have put some effort into "plugging" each implementation and planting a subtle bug in them. You never can tell.

It is not somuch the protocol what matters but the implementations.

Imagine they "rig" all those beatiful hardware RNG. Could you tell the difference?

Are you sure renowned developer X van Y is not an NSA mole?

Remember the OpenBSD IPSec backdoor allegation?

https://lwn.net/Articles/420858/

The protocol itself would still seem to be safe (or rather, have safe combinations of key exchange and encryption).

But it is certainly feasible that if they manage to find cracks in popular-but-old communications protocols that they are able to automatically decrypt them, or use prior key recovery successes to bootstrap fast attacks on new communications from the same host.

What would be interesting is if NSA's own "Suite B" crypto recommendations are susceptible to these risks, as that would potentially represent a rather significant break in the U.S.'s own COMSEC, and COMSEC is one of the things NSA is very specifically tasked with ensuring are safe with no backdoors for anyone to jump through.

Backdoors in the NSA recommendations could be due to trapdoor functions that only NSA has the key for. Other parties would therefore be unable to utilize that backdoor (short of the secret being exfiltrated).

Inserting such a keyed backdoor is much more difficult to do undetected, and more limited in scope (has to be done separately for every crypto algorithm being backdoored), than introducing a flaw in a hardware or software RNG implementation.

Reply on news.ycombinator.com