

CloudFlare, PRISM, and Securing SSL Ciphers - jgrahamc
http://blog.cloudflare.com/cloudflare-prism-secure-ciphers?

======
adamt
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.

[1]
[http://googleonlinesecurity.blogspot.co.uk/2013/01/enhancing...](http://googleonlinesecurity.blogspot.co.uk/2013/01/enhancing-
digital-certificate-security.html)

~~~
js4all

        > 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.

~~~
adamt
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.

~~~
MertsA
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.

------
tptacek
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.

~~~
nonane
Can you please expand on this? Does using TLS (vs SSL2v3) automatically ensure
you're using ephermal diffie hellman?

~~~
tptacek
No, it's a ciphersuite; the server and client have to agree to use it.

------
sweis
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.

~~~
MichaelSalib
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.

~~~
sweis
I think CDNs make the best effort with the tools they have. However, many PoPs
don't have locked racks, biometrics, or cameras.

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.)

------
Ihmahr
This article is about how difficult it would be for NSA to 'break' a cypher.

But couldn't they just go to the certificate authority and get the keys? What
could they then do with these keys?

~~~
MichaelSalib
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.

~~~
Ihmahr
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.

~~~
MichaelSalib
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.

~~~
duskwuff
> 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.

~~~
MichaelSalib
Sure, if we're talking about a small number of users. But this isn't going to
scale and it doesn't seem very cost effective.

------
leoc
> 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...](http://www.aclu.org/files/pdfs/natsec/faafoia20101129/FAAFBI0067.pdf)
) 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.

------
ctz
The content in this post is in the section titled 'SSL on CloudFlare'. The
text leading up to that is (at best) fluff and incorrect in parts.

~~~
jgrahamc
Please indicate what is incorrect and I will ask the CEO to correct.

~~~
ctz
Point by point:

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.

~~~
agwa
> 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]

[1]
[http://en.wikipedia.org/wiki/Transport_Layer_Security](http://en.wikipedia.org/wiki/Transport_Layer_Security)

~~~
ctz
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.

~~~
agwa
> 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).

------
alimoeeny
So does Google use a proprietary implementation, or there are open source
solutions to implement the ECHDE thing?

~~~
eastdakota
Not proprietary. OpenSSL supports ECDHE. Can use your standard SSL key issued
by any certificate authority.

------
tkorri
Didn't the companies (Google, Facebook etc.) just give the information to NSA,
or did I miss something?

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.

