Subscribe

One of the more infamous leaked NSA documents was a slide showing a
hand-drawn diagram of Google's network architecture, with the comment
"SSL added and removed here!" along with a smiley face, written underneath
the box for Google's front-end servers.

"SSL added and removed here! :-)"

The point of the diagram was that although Google tried to protect their
users' privacy by using HTTPS to encrypt traffic between web browsers
and their front-end servers, they let traffic travel unencrypted between
their datacenters, so their use of HTTPS was ultimately no hindrance to
the NSA's mass surveillance of the Internet.

Today the NSA can draw a new diagram, and this time, SSL will be added and
removed not by a Google front-end server, but by a CloudFlare edge server.
That's because, although CloudFlare
has taken the incredibly generous and laudable step of providing free HTTPS by default to all of their
customers, they are not requiring the connection between CloudFlare
and the origin server to be encrypted (they call this "Flexible SSL").
So although many sites will now support HTTPS thanks to CloudFlare,
by default traffic to these sites will be encrypted only between the user and the
CloudFlare edge server, leaving plenty of opportunity for the connection
to be eavesdropped beyond the edge server.

Arguably, encrypting even part of the connection path is better than the status quo, which provides
no encryption at all. I disagree, because CloudFlare's Flexible SSL will lull website visitors into a false sense of security,
since these partially-encrypted connections will appear to the browser as normal HTTPS connections,
padlock and all. There will be no distinction made whatsoever between a connection that's
protected all the way to the origin, and a connection that's protected only part of the way.
Providing a false sense of security is often worse than providing no security at all,
and I find the security of Flexible SSL to be quite lacking. That's
because CloudFlare aims to put edge nodes as close to the visitor as possible, which minimizes latency,
but also minimizes the percentage of an HTTPS connection which is encrypted. So although Flexible SSL
will protect visitors against malicious local ISPs and attackers snooping on coffee shop WIFI,
it provides little protection against nation-state adversaries. This point is underscored by
a
map of CloudFlare's current and planned edge locations, which shows a presence in
37 different countries,
including China. China has abysmal human rights and pervasive Internet surveillance, which is troubling
because CloudFlare explicitly mentions human rights organizations as a motivation
for deploying HTTPS everywhere:

Every byte, however seemingly mundane, that flows encrypted across the Internet makes it more difficult for those who wish to intercept, throttle, or censor the web. In other words, ensuring your personal blog is available over HTTPS makes it more likely that a human rights organization or social media service or independent journalist will be accessible around the world.

It's impossible for Flexible SSL to protect a website of a human rights organization from interception, throttling, or censoring
when the connection to that website travels unencrypted through the Great Firewall of China. What's worse
is that CloudFlare includes the visitor's original IP address in the request headers to the origin server,
which of course is unencrypted when using Flexible SSL. A nation-state adversary eavesdropping on Internet
traffic will therefore see not only the URL and content of a page, but also the IP address of the visitor
who requested it. This is exactly the same situation as unencrypted HTTP, yet as far as the visitor can tell,
the connection is using HTTPS, with a padlock icon and an https:// URL.

It is true that HTTPS has never guaranteed the security of a connection behind the host that terminates
the SSL, and it's already quite common to terminate SSL in a front-end host and forward unencrypted traffic to a back-end
server. However, in almost all instances of this architecture, the SSL terminator and the back-end are in the same datacenter
on the same network, not in different countries on opposite sides of the world, with unencrypted connections traveling
over the public Internet. Furthermore, an architecture where unencrypted traffic travels a significant distance behind
an SSL terminator should be considered something to fix, not something to excuse or encourage. For example,
after the Google NSA slide was released, Google accelerated their plans to encrypt all inter-datacenter traffic. In doing
so, they strengthened the value of HTTPS. CloudFlare, on the other hand, is diluting the value
of HTTPS, and in astonishing numbers: according to their blog post, they are doubling the number of HTTPS sites on the
Internet from 2 million to 4 million. That means that after today, one in two HTTPS websites will be using encryption
where most of the connection path is actually unencrypted.

Fortunately, CloudFlare has an alternative to Flexible SSL which is free and provides encryption between CloudFlare and
the origin, which they "strongly recommend" site owners enable. Unfortunately, it requires manual action on the part
of website operators, and getting users to follow security recommendations, even when strongly recommended, is like herding
cats. The vast majority of those 2 million website operators won't do anything, especially when their sites already appear
to be using HTTPS and thus benefit from the main non-security motivation for HTTPS, which is preference in Google search rankings.

This is a difficult problem. CloudFlare should be commended for tackling
it and for their generosity in making their solution free. However, they've only solved
part of the problem, and this is an instance where half measures are
worse than no measures at all. CloudFlare should abolish Flexible
SSL and make setting up non-Flexible SSL easier. In
particular, they should hurry up the rollout of the "CloudFlare Origin
CA," and instead of requiring users to submit a CSR to be signed by
CloudFlare, they should let users download, in a
single click, both a private key and a certificate to be installed on
their origin servers. (Normally I'm averse to certificate authorities
generating private keys for their users, but in this case, it would be
a private CA used for nothing but the connection between CloudFlare and
the origin, so it would be perfectly secure for CloudFlare to generate
the private key.)

If CloudFlare continues to offer Flexible SSL, they should at least include
an HTTP header in the response indicating that the connection was not encrypted
all the way to the origin. Ideally, this would be standardized and web browsers
would not display the same visual indication as proper HTTPS connections if this header is present. Even without
browser standardization, the header could be interpreted by a browser extension that could
be included in privacy-conscious browser packages such as the Tor Browser Bundle.
This would provide the benefits of Flexible SSL without creating a false sense of security,
and help fulfill CloudFlare's stated goal to build a better Internet.

Google recently announced
that they will be phasing out support for SHA-1 SSL certificates in Chrome, commencing almost immediately.
Although Microsoft was the first to announce
the deprecation of SHA-1 certificates, Google's approach is much more aggressive than
Microsoft's, and will start treating SHA-1 certificates differently well
before the January 1, 2017 deadline imposed by Microsoft. A five year SHA-1
certificate purchased after January 1, 2012 will be treated by Chrome as
"affirmatively insecure" starting in the first half of 2015.

This has raised the hackles of Matthew Prince, CEO of CloudFlare.
In a comment on Hacker News,
Matthew cites the "startling" number of browsers that don't support SHA-2
certificates (namely, pre-SP3 Windows XP and pre-2.3 Android) and expresses his concern
that the aggressive deprecation of SHA-1 will lead to organizations declining to support
HTTPS. This comment resulted in a very interesting exchange between
him and Adam Langley, TLS expert and security engineer at Google, who,
as you'd expect, supports Google's aggressive deprecation plan.

Matthew raises legitimate concerns. We're at a unique point in history:
there is incredible momentum behind converting sites to HTTPS, even sites
that traditionally would not have used HTTPS, such as entirely static
sites. The SHA-1 deprecation might throw a wrench into this and cause site
operators to reconsider switching to HTTPS. Normally I have no qualms
with breaking some compatibility eggs to make a better security omelette,
but I'm deeply ambivalent about the timeframe of this deprecation.
Losing the HTTPS momentum would be incredibly sad, especially since
switching to HTTPS provides an immediate defense against large-scale
passive eavesdropping.

Of course, Adam raises a very good point when he asks
"if Microsoft's 2016/2017 deadline is reckless, what SHA-1 deprecation date would be right by
your measure?" In truth, the Internet should have already moved
away from SHA-1 certificates. Delaying the deprecation further hardly
seems like a good idea.

Ultimately, there may be no good answer to this question, and it's really
just bad luck and bad timing that this needs to happen right when HTTPS
is picking up momentum.

This affects me as more than just a site operator, since I
resell SSL certificates over at SSLMate.
Sadly, SSLMate's upstream certificate authority, RapidSSL, does not currently
support SHA-2 certificates, and has not provided a definite
timeframe for adding support. RapidSSL is not alone: Gandi
does not support SHA-2 either, and
GoDaddy's SHA-2 support is purportedly a little bumpy. The fact
that certificate authorities are not all ready for this change makes
Google's aggressive deprecation schedule all the more stressful. On the
other hand, I expect RapidSSL to add SHA-2 support soon in response
to Google's announcement. If I'm correct, it will certainly show the
upside of an aggressive deprecation in getting lethargic players to act.

In the meantime, SSLMate will continue to sell SHA-1 certificates,
though it will probably stop selling certificates that are valid for more
than one or two years. Switching to a certificate authority that already supports SHA-2 is out of the question,
since they are either significantly more expensive or take a long time
to issue certificates, which doesn't work with SSLMate's model of real
time purchases from the command line. When RapidSSL finally adds SHA-2
support, SSLMate customers will be able to replace their existing SHA-1
certificates for free, and SSLMate will do its best to make this process
as easy as possible.

Speaking of certificate lifetimes, Adam Langley
made the case in the Hacker News thread that site operators should
purchase certificates that last only a year. I agree
heartily. In addition to Adam's point that short-lived certificates insulate
site operators from changes like the SHA-1 deprecation, I'd like to add
that they're more secure because certificate
revocation doesn't really work. If your private key is compromised, you're not truly safe until your
certificate expires, so the shorter the lifetime the better. The main
argument against short-lived certificates has always been that they're
really inconvenient, so I'm happy to say that at SSLMate I'm working on
some very exciting features that will make yearly certificate renewals
extremely easy. Stay tuned for an announcement next week.