The NSA doesn't need to break Google/Facebook/Twitter's private key. They just need to have bought/stolen/subpoenaed/cracked the private key of any CA that is in your browser. E.g. a mole inside GoDaddy/RSA or anyone with an intermediate chained certificate.
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.
> They just need to have bought/stolen/subpoenaed/cracked the private key of any CA
The CA's private key isn't involved in the encryption. It is used the sign the SSL certificate. Google's private key or a flaw in the crypto algorithm is needed to decrypt the traffic and that is most probably what the NSA is doing.
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.
If you have the private key of a trusted CA (e.g. a CA in the browser), then you can sign a certificate for any site.
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.
Well you would be right in terms of this working but if the NSA were doing this it would have been noticed. Also, that trick won't work when certificate pinning gets involved so going to Gmail in Chrome would pop up a warning message if they tried. Supposedly PRISM has access to Gmail so at the very least the NSA is doing something else in addition to selective SSL MITM attacks.
You can use something like Channel ID[1] to bind the D-H connection into the bearer token used for authentication (i.e., an OATH token). This won't protect against a MITM attack per se, but laptops and mobile devices tend to connect to a number of different networks, and if the MITM proxy is located close to the user, it's hard to make sure that all possible connection avenues from the laptop in question can be intercepted (including if the user hops on and off a VPN). If the user manages to connect to the server without going through the MITM, the channel ID will be different and so this can be noticed.
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.
> This would then enable a man-in-the-middle SSL attack.
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.
A man-in-the-middle attack done this way would be easy to detect. You just need to compare the site's key with the one you received, and they'd be different.
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.
You don't need elliptic curve to get forward secrecy from TLS; the ECC ciphersuites are very new, but the ephemeral Diffie-Hellman construction in TLS has been around for a long time.
Unfortunately, though, plain DHE is really slow, so it's pretty hardware-intensive to do it at scale, and to keep latency manageable. Google made a big deal out of moving to ECDHE the year before last, and part of that was that it allowed them to get perfect forward secrecy without sacrificing performance.
We just went through some similar stuff, having to ditch Amazon Linux for our SSL termination machine because Red Hat strips out all elliptic-curve crypto. It might also be worth investigating whether or not the Debian 7 OpenSSL build includes the optimized 64-bit ECDHE implementation contributed by Google, which wasn't enabled in Ubuntu's build until last month.
If you're terminating SSL in the edge network of CloudFlare or other CDNs, then your private key is going to be replicated to all their points of presence.
Keys will be vulnerable to anyone with access to those PoPs, which are generally ISPs.
I can't speak for other CDNs, but I know Akamai at least takes this extremely seriously. By seriously, I mean, machines that serve SSL are in locked racks with cameras and when unauthorized access occurs, the machines automatically wipe themselves. That's not complete protection but it gives you some assurance.
Certificate authorities don't have private keys. A CA could give the NSA the ability to forge certificates, which would allow the NSA to engage in active man in the middle attack, but that could be defeated with cert pinning.
ETA: of course CAs have their own private keys, but they don't have the private keys of their customers.
CAs do have private keys. Otherwise, what is the public key that I see on the Entrust Root CA related to? (The CA at the root of the hierarchy that issued HN's certificate)
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)
So if my entire website goes over ssl, could they still read or alter the secret content if they mitm by forging a certificate if the certificate is not pinned?
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.
If the federal government deploys its full weight against you, there's really not much you can do. Directed against one individual, then sure, an active MITM attack is feasible if you don't have cert pinning. I doubt it is cost effective though when compared to just filing a national security letter with the companies you're communicating with or putting malware on your box or installing a keylogger or just plain locking you in a room and beating you with a rubber hose until you tell them what they want to hear.
For a small website, sure. But it would be noticeable at the origin if you knew what to look for: all of the sudden your usual distribution of client IPs would be replace by a much smaller set of NSA IPs.
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.
> But it would be noticeable at the origin if you knew what to look for: all of the sudden your usual distribution of client IPs would be replace by a much smaller set of NSA IPs.
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.
Right, but the CA in that scenario has their own private key. If the private key for say Verisign was shared with the NSA, then the NSA would be able to MITM anybody using a cert that appeared to come from verisgn.
They can and they most probably have done that. Even Iran and China did it, stole root CA private keys, kind of sloppy because we know.
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.
The CA doesn't have/or need your private key. It works by signing your public key with its private key, thus affirming that you are whom you say you are. Think of it as getting a recommendation letter from your professor with his signature. Public and Private keys are also cryptographically related to each other, so a change in one will affect the other.
Yes, but they can't pretend that they are the company you are talking to... Or at least they'll leak enough information to get caught if they do that in a massive way.
Certificate pinning is just another attack vector, and MS/Apple/Google may all be keeping the NSA apprised of changes to browser/device certificate policies (inadvertently or otherwise).
Care to elaborate? I don't see how publishing a list of fingerprints of trusted certs would facilitate an attack. Especially given that the underlying certificates are public knowledge, sent as part of every HTTPS session.
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.
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"
The ECRYPT II Yearly Report on Algorithms and Keysizes suggests that an adversary with a budget of $10M should be countered with at least 78 bits of security, and that 1024-bit modulus RSA keys have 73 bits of security. I think this is a pretty good source on this sort of thing.
"Google is a notable anomaly. The company uses a 1024-bit key"
I've seen in the past Google presenting ECDSA server keys on P256, for some hosts and assuming your client advertises ECC with suitable extensions. Such keys are roughly equivalent in strength to 3248-bit modulus RSA keys.
"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."
An important note here: an active attacker can silently downgrade client connections to turn off PFS.
"(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.)"
This is dangerously misleading, even with the qualification. In fact, its around 2^30 times as strong. You really must assume your adversary is using the best available factoring algorithm, or your conclusions will be meaningless.
> An important note here: an active attacker can silently downgrade client connections to turn off PFS.
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]
The downgrade is done outside the SSL/TLS protocol, by browser vendors (sorry, I should've made it clear that that point was constrained to real-world deployments of HTTPS, rather than a property of the protocol itself).
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.
> 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).
> An important note here: an active attacker can silently downgrade client connections to turn off PFS.
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?
About your first point, the slide would seem to indicate that the NSA didn't start collecting data until the dates posted. So for whatever reason they didn't collect data until that point, it's not clear if they've actually been able to read any of that data yet.
> To date, CloudFlare has never received an order from the Foreign Intelligence Surveillance Act (FISA) court. ... 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.
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.
I suggest the paragraph be more clear on that, then. "We may however receive orders unrelated to FISA, in which case we are legally allowed to challenge the order."
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.
> To date, CloudFlare has never received an order from the Foreign Intelligence Surveillance Act (FISA) court. Moreover, we believe that due process requires court review of executive orders. As a policy, we challenge any orders that have not been reviewed and approved by a court.
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.
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...