CloudFlare, PRISM, and Securing SSL Ciphers
blog.cloudflare.com
blog.cloudflare.com
This would then enable a man-in-the-middle SSL attack.
There are some challenges about implementing this with just a port-mirror or TAP, but it is possible. For means of an easy example, you can see the DNS requests coming from an end-user for 'www.gmail.com' and fake the response (racing against the real name server's response). This then points the user to your website with your fake Gmail certificate. You then simply proxy the data along to the real gmail and you have obtained the password for that uses gmail.
This is the biggest weakness of SSL. Chrome now has protection [1] against fake google certificates. But for most sites/browsers you have little protection against this.
[1] http://googleonlinesecurity.blogspot.co.uk/2013/01/enhancing...
We know they are not doing this en-masse though. It would be noticed by now if they were. They undoubtedly do it, but almost certainly only targeting individuals, or all users of obscure sites.
Or, in simpler terms, that kind of attack would require the cooperation of several employees of the attacked companies. While just putting a mole there and copying the private key would require cooperation of only the mole in one of the positions that would need to cooperate at the other attack. (And breaking the key would happen only if the NSA wanted to give some easy money to computer manufacturers.)
Rougue certificate authorities are the biggest weakness of SSL from the point of view of a user that wants to be sure that it's really his bank that is asking for a password. But the endpoints security are still the biggest weakness against a powerfull oponent like the NSA.
> They just need to have bought/stolen/subpoenaed/cracked the private key of any CA
They are roughly 30 years ahead in crypto analysis. They have shown this when they gave us hints on hardening the current crypto algorithms to make them secure enough for todays use (like online-banking, secure ordering over the Internet etc). They however have no problems with them.
For various definitions of "roughly"...
Today? Who knows.
E.g. if your browser trusts RSA as a CA, and I had RSA's private key. Then I could create a new certificate for any site I want on the fly and sign it with a CA's key that your browser trusts.
There are several products that do this (E.g. Bluecoat's Proxy-SG) to filter/cache SSL traffic for enterprise customers. In these cases they just create their own in-house CA and add it to the standard install of all their corporate browsers. If you had the private key of any trusted certificate authority (and there's a scarily large number of them, including ones owned by governments) then you could create certs on the fly for any site and decrypt all traffic.
Trust me - I've built products that do this, and written entire an entire SSL stack from scratch.
[1] http://tools.ietf.org/id/draft-balfanz-tls-channelid-00.txt
If the MITM proxy servers are located close to the server, this problem goes away, but now the problem is since the ID information is passed after the D-H encryptionis established, and laptops move around, the MITM proxy would have to attack everyone's SSL connection. This increases the likelihood that someone will notice, and more importantly would require a huge amount of computing equipment. This is not something that you could hide in a phone closet --- and given how carefully most data centers measure power utilization and air conditioning load, a massive MITM proxy farm would be easily noticed.
Bill Binney has already said [1] this is exactly the case:
"No online cipher is safe...
Simply because if they don't have the key, they will come across and get it from you (that's assuming they didn't already implant it in your system).
The safest way is to do encryption offline, then go online and send it, and do decryption offline... If you don't have an air gap, you're not safe.
...I don't think they have to break [the encryption keys] at all. They already have them. That's my point. No online system is safe."
[1] http://techtv.mit.edu/videos/21783-the-government-is-profili... ~33 minutes
You can't control the client but you can have the server offer up a preferred list of ciphers.
On nginx, this would be ssl_prefer_server_ciphers = on; for example
Plain DHE is _killing_ our first load times...
I pestered peeps till they turned that flag on. As you said, it's now on for Ubuntu.
Keys will be vulnerable to anyone with access to those PoPs, which are generally ISPs.
This means CDNs are limited to where they can safely terminate SSL connections, which impacts latency and ultimately their bottom line.
(Disclaimer: I'm working on this problem.)
But couldn't they just go to the certificate authority and get the keys? What could they then do with these keys?
ETA: of course CAs have their own private keys, but they don't have the private keys of their customers.
the CA then verifies your identity, and then produces a certificate by signing (using their private key) the message digest of the concatenation of:
- certificate information: server name/organisation/country/... (the "subject"), start date, end date, etc
- your public key
- the subject of their certificate
your private key should never leave your system.
the NSA could then can use that to MITM sites without explicit pinning.
So when you look at the chain you see:
Verisign (lol j/k really the NSA) -> Site cert
Rather than:
Verisign -> Third party CA (suspicious) -> Site cert
If you pinned the site certs you should be able to defeat both of these.
Coercion by legal means, moles or good old hacking or planting bugged hardware in the targets system and extracting private keys. Its within the realms of NSA, remember, they have the capability to make their own processors.
But you're correct that even if the NSA got the CA's private key, they could only "forge" certificates and this would be detected by certificate pinning. (Similar to the Comodo/Digitnotar compromises)
Could they for example present a generic login and then mitm from thereon?
EDIT: Maybe ip traffic would reveal this. But what if they were to target an individual? I'm just trying to get to the bottom of this.
And there's no way they could scale it up to deal with google or facebook. They'd have to put start buying dozens of datacenters around the world and a vast amount of bandwidth. And they'd need to be able to hijack an enormous amount of traffic.
Honestly, it seems like buying up zero-day exploits and putting malware on people's computers would be oh so much easier and much much cheaper.
That's not a safe assumption. Given that this is the NSA we're talking about, it's probably within their capabilities to transparently MITM all connections to your server.
Nobody is accusing the NSA of MITM-attacking Google, Microsoft, etc, so I don't know why people keep bringing up certificate pinning.
His point was that if the NSA got to Google's certificate authority then they could use information within that private key to help decrypt Google's traffic.
I don't know how much water that theory/speculation holds, but I do know certificate pinning has nothing at all to do with this.
You can't get Google's private key from any cert authority. That's the point. If you compromise a cert authority, you can create fake certs to execute a man in the middle attack, but you can't passively decode encrypted traffic.
This needs to be clarified urgently. Anyone reading this would, quite reasonably, assume that this court review would (maybe among other things) seek to protect them from unreasonable search and seizure, that to get court approval the US government would (at least in principle) have to establish probable cause (or at least some kind of level of cause) of some crime (or at least some kind of bad behaviour). In fact, for non-US-citizens living outside the US this is apparently (IANAL) not the case. They appear to have quite literally no rights that the FISC court is obliged or entitled to uphold in the face of a FISA 702/FAA 702 order targeting them - neither rights under the Fourth Amendment, nor under FISA or any other law. From any specified non-resident alien the US government can seemingly take whatever data it wants, for any reason, without even having to state the reason to the court. Blatant industrial espionage? 100% OK. Watergate-style snooping for information to use in political dirty tricks? 100% OK. (The US government is completely clear that the purpose of FISA 702 is to eliminate the probable-cause requirement: http://www.aclu.org/files/pdfs/natsec/faafoia20101129/FAAFBI... ) Again, this will quite reasonably surprise people, who are used to for example having their US property protected by the Fifth Amendment even as non-resident aliens. Therefore CloudFlare's statement must make it clear and explicit to them that they are SOL once the US government decides it wants their data and that CloudFlare's demand for a court-approved order is a chocolate teapot when it comes to protecting them (as opposed to CloudFlare).
> As part of these challenges, we always request the right to disclose at least the fact that we received such an order but we are not always granted that request.
This could also use some clarification, since of the several thousand FISA orders served to other companies there doesn't seem to be any trace (IANAL) of one where the government has lifted the gag. The statement should make it clear that until there is a change of government policy, or law, or precedent then there is hardly a snowball's that CloudFlare's request will be granted.
Are you challenging orders you haven't received? It might help to be more clear. For all we know, CloudFare has been required to give all its data to the NSA. The law allows that, and the law could prevent CloudFare from disclosing it.
It might be best to be completely forthcoming. Let the customers know that their data can always be secretly read by the NSA with CloudFlare's assistance, even all customers' data, but you challenge what you are legally allowed to challenge. Or say nothing about it. As it is the text implies that the customers' data is better protected against snooping, which isn't possible and most everyone knows that now, so it leads to suspicion.
The first paragraphs make the mistake of assuming you need to break keys to collect SSL traffic (assuming no PFS). You can start collecting SSL traffic now, and break the keys at your leisure later on. I can see cases where breaking confidentially of contemporary communication even 10-20 years hence would be extremely valuable.
"Just the power necessary to run the server farm
needed to break a 1024-bit key would likely cost
in excess of $20M/year"
"Google is a notable anomaly. The company uses a 1024-bit key"
"This means that if the NSA, or anyone else, is
recording encrypted traffic, they cannot break
one private key and read all historical
transactions with Google."
"(Remember, for a naive algorithm, each bit doubles
the time it takes to break the key, so a 2048-bit
key isn't twice as strong, it is 2^1024 times as strong.)"
In retrospect, that this is possible seems obvious to me, but it had honestly never occurred to me before. I wonder why this isn't more widely discussed when talking about SSL security?
Are you sure this is true? SSLv2 didn't have any protection of the handshake so downgrade attacks were possible, but since SSLv3 the client and server send each other MACs of the handshake traffic so any tampering should be detected.
Quoth Wikipedia, TLS and SSL 3.0 provide "Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite." [1]
Browsers will start by sending a TLS1.something handshake. If that connection fails (due to a TLS alert, or TCP RST) then the browser starts the whole connection again with SSL3. This is to work around broken network appliances (of the sort made by Bluecoat and others) which cannot handle modern versions of TLS.
The only browser which has an effective countermeasure against this is Opera. CURL also does the right thing. I believe HSTS in Chrome also turns off this downgrade behaviour for hosts opting into HSTS.
I while back I surveyed the top 500 (Alexa) web sites, emulating the TLS behaviour of Chrome. Of the 321 sites supporting both SSL3 and TLS1, 86 (27%) chose different security parameters under downgrade conditions. Of these downgrades, 70 (81%) represented attacker-controlled loss of forward secrecy.
So this is the real problem - a minority of servers are misconfigured and won't use a cipher with forward secrecy under SSLv3. I just checked www.cloudflare.com and www.google.com and both use ECDHE even under SSLv3.
It would be really dangerous if browsers were willing to downgrade to SSLv2, which has no protection of handshake traffic, but SSLv2 has been disabled by default in browsers for years (Firefox even removed support for it altogether in FF8).
ssl_ciphers ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:RC4-SHA:AES256-SHA:DHE-RSA-AES256-SHA;
I don't see how SSL key length is relevant in the whole discussion if the weakest link is the company, not the transport method used.