
Announcing Keyless SSL - jgrahamc
http://blog.cloudflare.com/announcing-keyless-ssl-all-the-benefits-of-cloudflare-without-having-to-turn-over-your-private-ssl-keys/
======
lucb1e
For those who want to understand how it works (it took me a minute, so I'll
try to explain it simpler):

In simplified terms, the server usually stores a public and private key, and
sends the public key to the client. The client generates a random password,
encrypts it with the server's public key, and sends it to the server. Only
anyone with the private key can decrypt the message, and that should only be
the server.

Now you don't want to hand over this private key to Cloudflare if you don't
need to, because then they can read all traffic. Up until now, you needed to.

What they did was take the private key and move it to a keyserver, owned by
your bank or whomever. Every time the Cloudflare server receives a random
password (which is encrypted with the public key) it just asks the keyserver
"what does this encrypted message say?" After that it has the password to the
connection and can read what the client (the browser) is sending, and write
data back over the same encrypted connection. Without ever knowing what the
private key was.

The connection from Cloudflare to your bank's webserver and keyserver can be
encrypted in whatever way. It could be a fixed key for AES, it could be
another long-lasting TLS connection (the overhead is mostly in the connection
setup)... this isn't the interesting part and can be solved in a hundred fine
ways.

Edit: Removed my opinion from this post. Any downvotes for my opinion would
also push the explanation down (which I hope is useful to some). I mostly
agree with the other comments anyway.

~~~
personZ
_Now you don 't want to hand over this private key to Cloudflare if you don't
need to, because then they can read all traffic._

Generally the key you would give them is for, and limited to, the resources
that they cache/reverse proxy, so the same "read all traffic" concern exists.

What Cloudflare did is essentially, as others have mentioned, PKCS11 over the
internet. PKCS11 is an existing, very well proven technique of sequestering
the key in a hardware device, that hardware device doing what Cloudflare is
moving to the client location here. It's neat enough, but they seem to kind of
exaggerating the innovation a bit.

~~~
willvarfar
It is very obvious... In hindsight?

~~~
powertower
Not sure why all the negative reactions here... Was anyone else doing or
providing this type of "Keyless SSL" setup?

You'd think if this was a known technique, the mentioned banks would already
have been asking for it, implementing it, or doing it.

Personally, I think CloudFlare is one of the few companies on here doing
innovating stuff, and solving real issues.

And if not - if they've pulled the wool over my eyes - then at least I can
respect their marketing.

~~~
mentat
PKCS11 and Hardware Security Modules (HSM) have been around for a long time.
There's in wide use in companies like NetFlix and Square including "over the
network". This is not new.

------
indutny
And my patch for OpenSSL that does the same thing:
[https://gist.github.com/indutny/1bda1561254f2d133b18](https://gist.github.com/indutny/1bda1561254f2d133b18)
, ping me on email if you want to find out how to use it in your setup.

~~~
haberman
No disrespect meant, but from a security perspective the idea of patching
security-critical software with a patch from a stranger on the Internet is
kind of crazy, isn't it?

~~~
peterwwillis
All open source software is made up of patches from strangers on the internet.

~~~
haberman
Not really. Gatekeepers of important open-source software are usually people
who are known in the community and often employed by companies who work in the
area.

------
delinka
Instead of keeping the key in a potentially vulnerable place, they're putting
it in an oracle: pass ciphertext to the oracle, get plaintext back. I'm
interested in the authentication between CloudFlare and the oracle.
Cryptographic examples involving an oracle tend to refer to the oracle as a
black box that just blindly accepts data, transforms it, and replies. Of
course, then the oracle's content (a key, an algorithm) risks exposure through
deduction if an attacker can submit limitless requests. See
[http://en.wikipedia.org/wiki/Chosen-
plaintext_attack](http://en.wikipedia.org/wiki/Chosen-plaintext_attack)

I'm not at all suggesting that CF hasn't thought of this; rather I want to see
their mitigation of the risk.

~~~
davis_m
Would it be enough to simply only allow connections from Cloudflare IP
addresses?

~~~
jonknee
As Google and Yahoo will tell you after they found out the US government broke
into their dedicated lines between data centers... No. It must be encrypted at
every transfer without exception.

~~~
flyt
There's a huge difference between passively tapping a fiber optic cable and
infiltrating a network to inject malicious traffic. All we've ever seen
evidence of is NSA's passive tapping of Google & others.

~~~
staunch
We know the NSA targets routers. They have rootkits and remote exploits for
them. They can do packet injection or anything else with the traffic passing
through routers they take over.

------
mhandley
This seems to only slightly reduce the threat to the banks.

Currently, if someone compromises the Cloudfare servers, they gain the bank's
private key and can impersonate the bank until the bank revokes their keys.

With this solution, if someone compromises the Cloudfare servers, they can
impersonate the bank by relaying the decryption of the premaster secret
through Cloudfare's compromised servers back to the bank. They can do this
until Cloudfare notices and closes the security hole.

It's not clear that the difference is all that great in reality, as most of
the damage will be done in the first 24 hours of either compromise.

~~~
tokenizerrr
> Currently, if someone compromises the Cloudfare servers, they gain the
> bank's private key

This is not strictly true, is it? My interpretation is that at best they get
temporary access to a server that will sign for them using the key, but the
bank can terminate their signing servers at any time and then safely resume
using their key without having to revoke it, since it never left their server.

This does somewhat increase the attack surface, but it lets the bank keep
control over their keys and is better than having their keys get compromised
and thus having to revoke them.

~~~
sp332
Here, "currently" is the status quo, which is contrasted to "this solution".
So "currently" means "without this solution".

------
teddyh
So the communication between Cloudflare and the actual SSL key holder is
secured by… what? Another key? In that case, any compromise of Cloudflare’s
key is the same as a compromise of the original SSL key (at least in the short
term).

~~~
roc
A notable difference is that a compromise of Cloudflare's key wouldn't [edit:
might not] require the bank to notify the Federal Reserve.

It may be pretty cynical to call that situation a "feature". But I'm sure it
came up. And I'm sure they noticed.

It certainly wouldn't be the first time "trivial functional difference"
translated to "massive legal difference."

~~~
bkh
You should probably say "might not", because although we know a key compromise
would require notification, you'd have to have an actual lawyer tell you if a
compromise of CloudFlare would not. Unless the lawyers are on board with this
as a solution to the notification problem, the whole solution doesn't do
anything (legally).

~~~
roc
It gets a little cumbersome to hedge casual conversation the way attorneys do,
but sure, it would have been more accurate to have said:

"might not, under the current rules, which are always subject to change"

------
otterley
Keyless SSL is basically an analogue of ssh-agent(1) for OpenSSL. It's a nice
feature that you no longer have to trust CloudFlare with your private key, but
there's a huge tradeoff: if your keyserver is unavailable (ironically, due to
any of the things CloudFlare is supposed to protect you from or buffer you
against -- DDoS, network/server issues, etc.), they can no longer authenticate
requests served on your behalf and properly serve traffic.

~~~
motoboi
Please remember that CloudFlare is a sort of reverse proxy with some network
protections and enhancements.

If your infrastructure is unavailable, users won't get content anyway, SSL or
not.

~~~
otterley
CloudFlare can serve cached responses in the event that your origin server is
unavailable. This is particularly useful for static websites, but that's not
the most common use case.

~~~
peterwwillis
If your origin server can be found on the internet, it can be DDoS'd/attacked,
and your (dynamic) site will go down. This is true of all CDNs. The way to
avoid this is to either have the CDN host your app servers or provide a
private connection from your origin to the CDN.

I guess technically the TLS-secured _static_ content would now be at more risk
than it was before, when the cached content would have been served. But
existing session tickets would probably be honored, so only new clients would
get rejected. Still, it's a tradeoff some people would probably be fine with.

------
windexh8er
All other technicalities aside it's rather interesting. From an HSM
perspective it either makes that hardware now very useful or very useless.

Think of a large organization - you've been there (or not), there are 30
internal applications with self-signed certificates. Fail. The organization
had purchased an HSM, but never really got it deployed because - well, that
was too complex and it didn't integrate well with 3rd party network hardware
and failed miserably in your *nix web stack.

This could be interesting - and I'm not commenting with regard to the efficacy
or security concerns around this, but mainly the workflow simplicity it
provides to large organizations who end up in self-signed-cert-hell because
HSMs don't interoperate easily in a lot of use cases.

But to my original statement - this is a very good thing or a very bad thing
for Thales and the like. The only requirement for an actually certified HSM,
really, is certification against some hardware and software standard you have
a checkbox to fulfill. Beyond that this would be a killer in the middleground
for those who want an HSM like functionality but don't have any requirements
to meet other than housing a secure segment where key management can be done
in a more controlled manner.

~~~
reconbot
That's Hardware Security Module.

~~~
windexh8er
HSM = Hardware Security Module, yes, that was implied and my point.

------
vader1
While this is a cool feature, I wouldn't say the improvement is more than
marginal: all potentially sensitive customer data is still available to
Cloudflare in plain text. And after all, with a Business plan you can already
use your own ("custom") SSL certificate which you can then revoke at any time.

Why not offer a "pass through" mode where the proxying is done on the network
layer rather than the application layer? Of course in such a modus all CDN-
like functionality could no longer be offered, but it could still do a fair
amount of DDOS protection, no?

~~~
cbhl
Well, for the use case given, with "Keyless SSL", if Cloudflare is
compromised, then the bank doesn't need to report the incident to the Federal
Reserve.

But yes, users' plaintexts would still be compromised.

"Security theatre" indeed.

~~~
dfc
I am not sure that a Cloudflare compromise would not rise to the level of a
reportable event. In my experience/opinion "users' plaintext compromise" is
certainly an instance of unauthorized access to customer information. I
understand the whole framework here is risk-based so it is a matter of
interpretation; but I do not want to be the person who has to explain to the
nice folks from the OCC the intricacies of Cloudflare's implementation and why
I deemed the compromise low risk.

    
    
      >  An institution should notify its primary Federal regulator as soon
      >  as it becomes aware of the unauthorized access to or misuse of
      >  sensitive customer information or customer information systems.
    

FDIC: Supervisory Insights
[https://www.fdic.gov/regulations/examinations/supervisory/in...](https://www.fdic.gov/regulations/examinations/supervisory/insights/siwin06/article01_incident.html)

------
mback2k
So, this is not actually keyless SSL but SSL using something like a Hardware
Security Module over networked PKCS#11. Did I miss something?

------
praseodym
So CloudFlare won't get your private key, but will still get to see
unencrypted plaintext for all traffic? Sounds like a huge improvement...

~~~
jgrahamc
What threat are you concerned about?

~~~
praseodym
I don't really see the security improvement. Actually the key server would be
an new attack vector, although one that could be firewalled pretty well.

~~~
sarciszewski
Using CloudFlare implicitly requires trusting CloudFlare.

With this, CloudFlare cannot impersonate you without your endpoint's active
consent. As soon as you terminate the service that solves this puzzle for CF,
they cannot impersonate you any longer.

So, yes, it is better. Maybe not "great" if your threat model includes CF
getting 0wned, but definitely better than giving over your RSA key. ;)

~~~
marcosdumay
And that's why regulations make it almost impossible for banks to use
CloudFare. But CloudFare sees that as a problem, and makes some effort to
create a loophole.

You can't claim that this improves the bank clients' security. It's clearly
worse than doing nothing.

~~~
sarciszewski
Think of it as a compromise: You can leverage CloudFlare's CDN to mitigate
DDoS and other sorts of nasty attacks AND assure TLS is used with every
connection, without giving up your RSA key.

"It's clearly worse than doing nothing." It's not very clear to me. Please
explain.

~~~
km3k
I think "It's clearly worse than doing nothing" is from a purely security
perspective. This opens up a larger attack surface, so it's worse in terms of
security. But it's better than doing nothing from a business perspective,
since it allows for better performance and better handling of DDOS attacks.
It's a comprimise. Potentially it is slightly worse in security, but it is
much better for performance and uptime.

------
zaroth
See: Secure session capability using public-key cryptography without access to
the private key.

[https://www.google.com/patents/US8782774](https://www.google.com/patents/US8782774)

~~~
ivanr
And here's a similar patent from Akamai (via @cloudpundit)
[http://www.google.com/patents/US20130156189](http://www.google.com/patents/US20130156189)

~~~
zaroth
Looks like the Akamai patent for basically the exact same process, filed
2012-12-14, priority date 2011-12-16 is still being examined... yet the
CloudFlare patent filed 2013-03-07 was granted 2014-07-14.

That's a really fast turnaround for CloudFlare, and not sure how the Akamai
filing isn't prior art. Actually, the Akamai filing is _referenced_ in the
CloudFlare patent.

~~~
makomk
From what I can tell, the main difference is that the claims in CloudFlare's
patent describe more of the SSL handshaking process and the subsequent
handling of requests (all of which is exactly the same as in standard HTTPS
proxying). They both claim exactly the same technique for a web proxy to
handle SSL connections without having the private key, but I guess the USPTO
decided the fact that CloudFlare described more of that process in their
patent claims constituted a improvement on Akamai's invention for some weird
reason.

------
xorcist
The article is somewhat light on content. There are standard protocols for HSM
use. What is the reason you didn't use these? There are clear risks involved
with inventing your own security related protocols.

~~~
jgrahamc
We have a really long technical blog post coming tomorrow. Agree that
inventing protocols is dangerous so we got iSEC Partners/Matasano to evaluate.

------
_pmf_
Are we reinventing Kerberos again?

------
blibble
isn't this completely missing the point, i.e. banks being able to say 'no
third parties can see our clients identifying information/balances/etc?'

yes, the SSL key doesn't leave the bank, but everything it is protecting is..

~~~
indutny
It only protects one thing - server identity. The best ciphers do you use DHE
for negotiating the key, so the conversation between bank and the client is
secure anyway.

~~~
jtgeibel
Under this scheme, the DHE is between the client and CloudFlare, not the
client and the true end-point. CloudFlare still sees the full plaintext of the
HTTPS session (as it must in order to do it's magic). The encryption is not
end-to-end.

------
bjornsing
> World-renowned security experts Jon Callas and Phil Zimmermann support
> CloudFlare's latest announcement sharing, “One of the core principles of
> computer security is to limit access to cryptographic keys to as few parties
> as possible, ideally only the endpoints. Application such as PGP, Silent
> Circle, and now Keyless SSL implement this principle and are correspondingly
> more secure.”

Ehh... I'd say Keyless SSL implements the _opposite_ of that principle:
encryption terminates with CloudFlare but authentication terminates in some
bank.

------
yk
So the problem is, how to get a cloud in the middle while keeping the green
lock in the browser? Just yesterday I read Douglas Adam's phrase "technologies
biggest success over itself."

------
kcbanner
Interesting, but what about the latency issues of having to always contact the
key server?

~~~
jgrahamc
There's a very technical blog post coming on this tomorrow, but that problem
is addressed by session tickets and by the fact that most of the TLS handshake
is occurring with a CloudFlare server typically nearer the web browser than
before.

~~~
Rapzid
Do you guys have a "global" session ticket cache shared amongst endpoints? Or
do you ensure the same user gets routed back to the same termination node? I'm
quite curious about this.

~~~
eastdakota
Session Tickets are shared globally. Session IDs are shared intra-data center
(so regionally). The former works with Chrome/Firefox. The latter with all
other browsers.

~~~
Rapzid
That's really cool, thanks for responding. I imagined that possibility but
never heard of anyone actually doing it(not to say they don't). Maybe I'll
need to experiment around with Golang's TLS package :)

------
sarciszewski
That is amazing. I can't wait to play with this code :D

------
yusyusyus
How does this architecture address PFS? I'm guessing a future version would
require the exchange of DH private key to make it work...

~~~
agwa
Nothing that complicated is required. When the server needs to sign the DH
handshake, it sends the value to be signed over to the key server, and the key
server replies with the signature.

Although the diagrams in the blog post show the non-PFS RSA handshake, I'm
sure the architecture already supports the PFS DH handshake too.

------
ambrop7
I don't like to sound hateful, but this is an obvious solution that any
competent person knowing how TLS works would find. If someone tried to patent
it, I suppose every smart card would be considered prior art. The only
"novelty" is that the connection to the "smart card" is the network.

Not to say that it's not useful, but the article describes it as some grand
invention.

~~~
pilsetnieks
Then again, do you know of anyone else who has actually implemented and are
using this commercially, at scale? They say it themselves in the article, a
prototype is one thing but actually making it into a commercially viable
product is something else.

------
general_failure
Well, cloudfare can still read all the traffic. I thought that problem had
been solved somehow.

------
diafygi
Is this the free SSL announcement that CloudFlare said it was going to
announce in October?

~~~
jgrahamc
No.

~~~
sarciszewski
Is it related? ;)

~~~
xxdesmus
not really -- only in that they are both SSL-related.

Free SSL is still in the works. More info soon-ish.

~~~
sarciszewski
My question was more to the point of: will Keyless SSL work with Free SSL? :)

~~~
eastdakota
Not how you're likely thinking. That said, we will use the Keyless technology
to expand our data center footprint into locations that we wouldn't feel
comfortable storing customers' keys. That will end up benefiting even Free
customers who will be faster around the world.

------
EGreg
Wow, what a great read!

------
liricooli
It seems that the correct title should have been "all your keys are belong to
us".

------
personZ
After reading the beginning of the piece, I was expected something
more...profound. Some deep mathematical breakthrough or something.

Instead they separate the actual key signing, delegating it to the customer's
device. That's nice and useful, but isn't quite what I was expecting.

~~~
Mawaai
"Tomorrow, we'll publish a full post on the nitty, gritty techical details of
how, what has come to be called Keyless SSL™, works."

~~~
jldugger
But it's already fairly obvious how it works. They essentially MITM with the
keyserver to receive the SSL nonce. Of course, it's pretty silly to expect
cloudflare to have some special mathematical revolution to solve the stated
problem. In fact I figure if you could terminate SSL without an online private
key, the encryption scheme is simply broken.

~~~
personZ
_But it 's already fairly obvious how it works._

It is obvious, and they effectively implemented a custom approach for
PKCS11/ssh-agent. Yet the narrative implies some brilliant period of insight
and innovation, when really it kind of isn't.

Which is where the "silly" notion that they must have did something novel came
from -- their narrative claims it.

~~~
giovannibajo1
Innovation means different things to different people. To you, it seems to
mean a mathematical or algorithmic breakthrough. To me, it also means getting
an existing idea or technology, and deploying it in a new, real-world context,
solving the UX / scalability / security / policy issues that arise in the new
context, and make it commercially viable.

The fact that Cloudflare is the first global-level CDN to implement this kind
of keyless SSL termination to me _is_ innovation, even though it's based on
pulling PKCS11 at the IP level. It's solving a real-world problem in their
context, which nobody has solved before, and customers pay for it.

------
zameericle
Sounds like Elliptic Curve Diffie-Hellman is used between client/server to
establish a private key. Not sure how this is new.

~~~
sarciszewski
At a glance, it appears that the non-ephemeral RSA signature is handled in the
network, but the key exchange occurs at the endpoint.

What's new is the whole "edge calls home with a signing request" piece.

------
ilaksh
This is a discussion about cyberwarfare in a literal sense. The technical
discussion shouldn't really be separated from the economic, political, social
and human health concerns because all of those parts of the system interact
deeply and directly.

A goal of total political cooperation or submission leads to economic
sanctions leading to serious human health effects leading to defensive denial
of service attacks. This accelerates the need to decentralize the financial
network systems to make them more robust.

How can we imagine though that even after a complete transition to next
generation systems that are ground-up distributed designs (not just stop-gap
tweaks like this) that we won't have new types of attacks to deal with.

The starting point is the belief system that provides such fertile ground for
conflict. We have to promote the idea that human lives have value and that
lethal force is not an acceptable way to resolve conflict.

As long as decision makers are living in a sort of 1960s James Bond fantasy
world we will all be subject to the insecurity of that type of world. Its
largely built upon a type of primitive Social Darwinism that is still much
more prevalent than most will acknowledge.

Its much easier to accept a compartmentalization of these problems and focus
on a narrow technical aspect, but that does not integrate nearly enough
information.

~~~
ilaksh
Would be interested to hear from people who are burying my comment if they
have any kind of explanation for why they are doing it, such as counterpoints
to my statements. In case there is some insight that I might gain from them,
since apparently there is a strong disagreement.

~~~
jessaustin
GP comment is too generalized to be constructive. That is especially so in
this discussion of a specific network security platform, which presumably has
specific faults that may be discussed instead of generalities like "belief
systems" and "human lives".

~~~
ilaksh
You're right, I'm sure none of my general concerns about completely false
belief systems and human lives are worth being viewed by any readers in this
thread. My comment also may be a little bit difficult to contextualize or
disconcerting for readers. Best to keep downvoting it so that it disappears.

~~~
Gigablah
Passive-aggressiveness is not an effective persuasion technique.

