Over the last week we’ve closely watched the disclosures about the
alleged NSA PRISM program. At CloudFlare, we have never been approached
to participate in PRISM or any other similar program. We do, from time
to time, receive subpoenas and court orders. A human being on our team
reviews each of these requests manually. When we determine that a
request is too broad, we push back to limit the scope of the request.
Whenever possible, we disclose to all affected customers the fact that
we have received a subpoena or court order and allow them an opportunity
to challenge it before we respond.

One of the ways we limit the scope of orders we receive is by limiting
the data we store. I have written before about how CloudFlare limits what we log
and purge most log data within a few hours. For example, we cannot
disclose the visitors to a particular website on CloudFlare because
we do not currently store that data.

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

While we understand the need for secrecy in some investigations, we are
troubled when laws limit our ability to acknowledge that we have even
received certain kinds of requests. CloudFlare fully supports the calls for transparency
today by other web companies like Google, Microsoft, and Facebook. At a
minimum, we request the law be updated to allow companies to disclose
the number of FISA orders and National Security Letters (NSLs) they
have received. We believe this is a modest request which does not harm
the integrity of legitimate investigations while allowing for an
informed public debate over the use of these measures.

As we set policy, one of our guiding principles is that we should
neither make the job of law enforcement easier, nor should we make it
harder, than it would have been if CloudFlare did not exist. If the NSA
is listening in on any transactions traversing our network, they are not
doing so with our blessing, consent, or knowledge.

Making Sense of PRISM

As we’ve followed the PRISM story, we’ve tried to reconcile how the
PRISM slides could be accurate while so many tech executives have denied
participation in the program. One theory that surfaced was that the NSA
had broken the private SSL keys of a select number of web giants. Our
theory was that this could explain how companies were added over time —
as their private SSL keys were cracked — while their executives
wouldn’t have any knowledge of what was happening.

Even the name of the program — “PRISM” — led credence to this theory.
Prisms are often used with fiber optic cables in order to split the
light the cables carry into multiple copies. This is not new technology.
In 2006 in Room 641a of a data
center in San Francisco, AT&T installed a beam splitter to siphon
traffic from their optical network, reportedly at the request of the
NSA.

SSL should protect these communications. However, with most SSL ciphers,
the private key remains the same for all sessions. As a result, if the
NSA were to record encrypted traffic, they could later break the SSL key
used to secure the traffic and then use the broken key to decrypt what
they previously recorded.

Breaking SSL

Breaking a SSL key is hard, but not impossible. Doing so is just a
matter of computational power and time. For example, it is known that
using a 2009-era PC cranking away for about 73 days you can reverse engineer a 512-bit key.
Each bit in a key’s length doubles the effective computational power
needed to break the key. So, if the key were 513 bits long, you’d expect
the same modest PC 132 days to break the key. These tasks are highly
parallelizable, so if you have two modest PCs then you’d expect the
time to break the 513-bit key to drop down to 66 days again.
(Note: this assumes a naive factorization algorithm. The state of the
art is to use a generalized number field sieve. This
reduces the rate of complexity growth to something that is sub-exponential.
This means if you know what you’re doing the problem doesn’t double in
difficulty with each additional bit.)

It is not inconceivable that the NSA has data centers full of
specialized hardware optimized for SSL key breaking. According to data
shared with us from a survey of SSL keys used by various websites, the
majority of web companies were using 1024-bit SSL ciphers and RSA-based
encryption through 2012. Given enough specialized hardware, it is within
the realm of possibility that the NSA could within a reasonable period
of time reverse engineer 1024-bit SSL keys for certain web companies. If
they’d been recording the traffic to these web companies, they could
then use the broken key to go back and decrypt all the transactions.

While this seems like a compelling theory, ultimately, we remain
skeptical this is how the PRISM program described in the slides actually
works. Cracking 1024-bit keys would be a big deal and likely involve
some cutting-edge cryptography and computational power, even for the
NSA. The largest SSL key that is known to have been broken to date is
768 bits long. While
that was 4 years ago, and the NSA undoubtedly has some of the best
cryptographers in the world, it’s still a considerable distance from 768
bits to 1024 bits — especially given the slide suggests Microsoft’s key
would have to had been broken back in 2007.

Moreover, the slide showing the dates on which “collection began” for
various companies also puts the cost of the program at $20M/year. That
may sound like a lot of money, but it is not for an undertaking like
this. Just the power necessary to run the server farm needed to break a
1024-bit key would likely cost in excess of $20M/year. While the NSA may
have broken 1024-bit SSL keys as part of some other program, if the
slide is accurate and complete, we think it’s highly unlikely they did
so as part of the PRISM program. A not particularly glamorous alternative
theory is that the NSA didn’t break the SSL key but instead just cajoled
rogue employees at firms with access to the private keys — whether the
companies themselves, partners they’d shared the keys with, or the
certificate authorities who issued the keys in the first place — to turn
them over. That very well may be possible on a budget of $20M/year.

Making SSL More Secure

Today many web companies have largely transitioned from 1024-bit SSL to
significantly stronger 2048-bit keys. (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.) Based on the SSL
survey data, Twitter has led the way, shifting 100 percent of its HTTPS
traffic to a 2048-bit key in mid-2010. By the end of 2012, the following
websites had approximately the amount of requests in the parenthesis
shifted to 2048-bit SSL:

• outlook.com (100%)
• microsoft.com (98%)
• live.com (90%)
• skype.com (88%)
• apple.com (85%)
• yahoo.com (82%)
• bing.com (79%)
• hotmail.com (33%)

Facebook is the laggard of the bunch and today is still using a 1024-bit
key for all HTTPS requests.

Google is a notable anomaly. The company uses a 1024-bit key, but,
unlike all the other companies listed above, rather than using a default
cipher suite based on the RSA encryption algorithm, they instead prefer
the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) cipher suites.
Without going into the technical details, a key difference of ECDHE is
that they use a different private key for each user’s session.
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. The NSA would have to break the private key
generated for each session, which, in Google’s case, is unique to each
user and regenerated for each user at least every 28-hours.

While ECDHE arguably already puts Google at the head of the pack for web
transaction security, to further augment security Google has publicly announced
that they will be increasing their key length to 2048-bit by the end of 2013.
Assuming the company continues to prefer the ECDHE cipher suites, this will
put Google at the cutting edge of web transaction security.

SSL on CloudFlare

There is good news in all of this. If you’re using SSL on CloudFlare,
your site is already at this cutting edge. We issue 2048-bit keys by
default and prefer the ECDHE cipher suites. Today, most modern browsers
running on up-to-date operating systems will support ECDHE. In our
tests, approximately two thirds of HTTPS requests to our network support
ECDHE. The remaining traffic quietly falls back on a more standard
cipher suite without the visitor noticing.

Looking Ahead

Ultimately, CloudFlare’s value proposition is built on trust. Core to
that trust is ensuring transactions passing through our network are
fundamentally secure. We will continue to work on both policy and
technology to ensure the security and integrity of our network.

PRISM has sparked a conversation on privacy and transparency broadly —
among citizens, between companies, and with our governments. At
CloudFlare, we are actively engaged in this conversation at many levels.
Our mission is to build a better web and we believe privacy and
transparency are critical to its foundation.

Via Cloudflare.com