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.
