
Keyless SSL: The Nitty Gritty Technical Details - jgrahamc
https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/
======
vader1
Interesting how they specifically refer to yesterday's discussion here on HN
and over at Reddit, but don't go into the frequently mentioned complaint that
despite not having access to the PK itself, Cloudflare can still intercept and
modify all cleartext sent between the client and server, which for most
intents and purposes means pretty much the same. Maybe not intentionally so,
but it comes off as slightly misleading, because many people I spoke to who
briefly skimmed the original announcement thought "keyless SSL" would mean
this is no longer the case.

Let me ask again: why not offer a setup where Cloudflare only acts on the
network layer instead of on the application layer and proxies the still-
encrypted HTTPS packets to the destination server? This would mean a customer
could not use Cloudflare's caching (CDN) features, but still enjoy their DDOS
protection without them being able to see all my customer's private details.
If I were the CISO at one of the world's largest banks, that is exactly what I
would want.

~~~
jgrahamc
Because DDoS protection isn't just something you do at the network layer. It's
important to be able to apply filtering at the "application" level.

~~~
vader1
I understand that there are many different types of DDOS attacks, and that for
some of them having access to the content on the application level makes your
job of mitigating them a lot easier.

But even without that, would comparing the encrypted traffic patterns for an
individual client to other client's patterns (or to that client's traffic to
one of the other 2 million Cloudflare websites); and analyzing the encrypted
traffic as in [1] not still give you a wealth of information to use? It might
have made for a much more rewarding two years of development: even if such a
setup would be slightly less effective at mitigating DDOS', it would be
infinitely better in terms of privacy and trust.

[1] [http://arxiv.org/abs/1403.0297](http://arxiv.org/abs/1403.0297)

~~~
jgrahamc
In some ways what you propose sounds even scarier, i.e. figure out the best
way to look inside SSL encrypted data without having the key.

But in terms of privacy and trust, CloudFlare is already in the position of
terminating SSL connections and establishing new ones to origin web servers.
We take the protection of that data and the associated keys very seriously.
There will be more announcements over the coming weeks and months about how we
secure things.

~~~
vader1
I'm not quite following how having just enough insights about the encrypted
data to perform DDOS mitigation would be scarier than having full read- and
write access to the cleartext. Thanks for the responses though, and definitely
looking forward to those blogs.

~~~
buro9
You are implying something fundamental: that the encrypted traffic could be
adequately analysed for insight without the need for decryption.

Yet to do so would be to defeat SSL itself, or at least to declare it as
insufficient to adequately protect secrets.

What CloudFlare is doing isn't defeating SSL or any kind of attack on it. They
are merely working around some prior limitations on requiring access to an
organisation's private key.

As a proxy that is charged with DDoS protection (and other types of protection
and performance improvements), they _are_ being asked _to_ terminate and work
on the unencrypted data to a very strict set of complience by the end
organisations, but they need to do this in a way that does not involve
possessing or having access to the private key.

Their solution works extremely well given the multiple constraints
(technological and legal) that they have.

~~~
handsomeransoms

      > You are implying something fundamental: that the encrypted traffic could be adequately analysed for insight without the need for decryption.
      > Yet to do so would be to defeat SSL itself, or at least to declare it as insufficient to adequately protect secrets.
    

This is possible through HTTPS traffic analysis, see [0] and [1] for starters.
Of course, it's much easier for Cloudflare to do analysis for DDoS protection
if they have access to plaintext.

Whether this means that SSL is, as you say, "insufficient to adequately
protect secrets" is an interesting discussion to have.

[0] [http://arxiv.org/pdf/1403.0297.pdf](http://arxiv.org/pdf/1403.0297.pdf)

[1] [http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-
goo...](http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-
maps.html)

------
justinsb
To save people a long read, there's nothing particularly surprising in these
details. The key is held by the origin; when a computation using the key is
needed the origin is asked to perform it over a secure connection. They have
improved support for session resumption in a distributed environment (which is
even more important now that key computations are even slower), this is
commonly done as closed-source, and CloudFlare have promised to open-source
it.

Good improvements, and session resumption is important to implement, but
nothing groundbreaking.

~~~
fathom108
Oh well. Guess we'll have to wait for Homomorphic encryption:

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

------
alexwilliamsca
The Keyless SSL server is open source and available on GitHub -
[https://github.com/cloudflare/keyless](https://github.com/cloudflare/keyless)
\- although I'm wondering if its dependence on OpenSSL was a good choice.

~~~
pricechild
Open source but a rather restrictive license!

~~~
josephlord
The source is published but it wouldn't count as a OSI open source licence.

Also note the patent mentioned in yesterday's discussion.

------
bifel
I don't get it. What's the point in keeping the key secret from cloudflare
whilst providing a key server signing everything it is asked to sign? Isn't
this like "Sorry I don't trust you enough to provide you a key to my
apartment. But if you need something, just ask the janitor, he'll open the
door any time you want"?

~~~
wsh
If you no longer trust the person, it's easier to tell the janitor not to
admit him than to rely on his returning the key (and any copies) or to change
the lock on the apartment.

~~~
bifel
Is "changing the locks" (revoking the certificate) really so complicated that
this "janitor-solution" is easier/cheaper/safer?

~~~
wsh
The CA can revoke the certificate, but since revocation checking in browsers
is neither universal nor reliable under attack, revocation isn't a completely
effective way to recover from a compromised private key.

------
yalogin
Why should all of these have a marketing spin to them? By that I mean a catchy
name. Keyless SSL is very misleading. I guess after the stupendous success of
the heartbleed bug marketing every one now wants a catchy name.

Having said that is it solving any security problems?

1\. Companies don't have to give out their private key to Cloudflare but they
still give them the encryption and hmac keys. So nothing really changed from a
privacy or data protection point of view.

2\. Now they opened up a new public API on the company's server for cloudflare
to use the private key.

3\. Is it simply to mitigate against another heartbleed kind of bug? Whats
preventing the same bug to appear in the company's server?

------
xorcist
Interesting read. Still no information how it compares to other HSM
implementations however, and why they didn't use the more well studied PKCS
protocols in theirs.

I would imagine the problem was more with existing implementations rather than
some problems with HSMs per se, as they probably have much larger latency than
you normally have so things like blocking reads start to matter.

~~~
ctz
I guess you mean PKCS#11, but that isn't a protocol. It's a C API. Trying to
funnel it over a network would be both extremely complex, and non-standard.

~~~
xorcist
No, I was thinking of PKCS#7 which you can run over IP if you want. But it's a
complicated set of standards and I'm not sure how they inter-relate. That's
why I summarized them as PKCS-style protocols.

This is not some theoretical thing. You can buy these devices off the shelf.
If you have worked with PKI you have seen them, or some variant thereof.

~~~
ctz
Yup, I know. My day job used to be writing firmware for nCipher/Thales HSMs :)

~~~
xorcist
Cool! We had those at a previous job. Good stuff.

------
spindritf
Is this all the software necessary to run your own little keyless-like
infrastructure with a couple of nginx server not having a key and talking to
this reference key server over the Internet?

BTW I probably should have asked yesterday but which CloudFlare plans will
include the keyless feature?

------
ehPReth
Sorry if I'm missing something, but shouldn't this be called "Keyless TLS" as
CloudFlare uses TLS and not SSL for this program?

~~~
kisielk
From the article:

"This may seem confusing at first, but makes sense since TLS is just a minor
update to SSL 3.0. Subsequent versions of TLS have followed this pattern.
Since TLS is an evolution of the SSL protocol, people still use the terms TLS
and SSL somewhat interchangeably."

~~~
ehPReth
Oops, must have missed that. Thanks! I'm personally a fan of using the new
official name whenever possible but I understand the tradition/ingrained
nature of SSL.

------
mrfusion
So from a non-technical business owner perspective this means I can offer SSL
for free without buying certs or making changes to my server?

~~~
peterwaller
No. This allows a content delivery network (such as cloudflare) to host
content on your behalf without having to have direct access to your private
key material.

The main use cases you may be interested in are to 1) make it so that users
connecting to you get a faster experience - since they can connect to a
geographically nearby cloudflare server, rather than your distant server and
2) make it so that cloudflare can absorb large denial-of-service attacks that
your server couldn't otherwise cope with.

~~~
mrfusion
Ok thanks. So this basically makes it easier and more secure to get set up
with cloudflare?

So why couldn't Cloudflare set up what I'm suggesting? Are there technical
reasons, or just lack of demand?

~~~
icebraining
To serve SSL for your domain, Cloudflare needs a certificate for your domain
issued by an accepted CA, which _someone_ needs to buy.

The only way for them to set that up would be to become a CA, get browsers to
accept their master certificate and then issue their own certs for their
clients.

~~~
ianlevesque
They actually do offer a service where they proxy your plain-text HTTP to end
users as HTTPS and provide a certificate. It's extremely convenient.

~~~
icebraining
Yes, but you still need to buy and give them a certificate, right? The
question included "can offer SSL for free without buying certs", which is not
possible, AFAIK.

~~~
ianlevesque
No, they essentially add your domain to a list of domain names in their own
certificate.

~~~
icebraining
Really? And their CA allows that? That's amazing.

------
higherpurpose
It's one thing to keep SHA1 in old services, but why do they keep pushing SHA1
into _new ones_?

~~~
rakoo
From the user POV, nothing is changed. The decision to deprecate SHA1 or not
isn't specific to Keyless SSL (ie, Keyless SSL isn't a new product for the
users)

From the bank's point of view, where we can say that Keyless SSL is a new
product, only 2 cipher suites are allowed:

    
    
        ECDHE-ECDSA-AES256-GCM-SHA384
        ECDHE-RSA-AES256-GCM-SHA384
    

which, as you can see, don't include sha1.

