Announcing Keyless SSL

http://blog.cloudflare.com/announcing-keyless-ssl-all-the-benefits-of-cloudflare-without-having-to-turn-over-your-private-ssl-keys/

by jgrahamc • 12 years ago

509 184 12 years ago

blog.cloudflare.com

teddyh• 12 years ago

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

spacefight4• 12 years ago

Same thought here. And what if that connection breaks? Another single point of failure?

jgrahamc8• 12 years ago

Multiple connections between CloudFlare and the Keyless SSL Server running at the customer site. Connections are reused, pipelined, load balanced etc.

jgrahamc8• 12 years ago

The communication between CloudFlare and the Keyless SSL Server at the customer site is mutually authenticated TLS 1.2 with a specific set of cipher suites.

Someone12342• 12 years ago

So if someone breaks into a CloudFlare server, can they steal the CloudFlare private key and then make unlimited numbers of requests against the e.g. bank's oracle?

Aren't you now still depending on certificate revocation but have just shifted the problem downstream (it is now the bank's job to revoke you, rather than the user's browser's job).

Or do you yourselves use "Keyless" technology, so that CloudFlare servers contact some CloudFlare oracle so that they can communicate with the bank oracle?

amalcon• 12 years ago

Yes, I've seen designs for this sort of thing. It's super scary, because you're essentially offering a decryption oracle with your private key to the Internet. It's authenticated, sure, but even still you've actually increased your attack surface.

A compromise of an SSL terminator, or the ability to pretend to be one, gives the same capabilities as a compromise of the oracle itself. The advantage you get is that only the last requires you to revoke and reissue the key when you figure it out(in other cases, simply unplug the oracle). That's relatively minor most of the time: an open decryption oracle is already hair-on-fire levels of bad.

I can see why some organizations (for whom this process is unusually expensive) might be interested, but it probably isn't beneficial most of the time.

Someone12342• 12 years ago

Here's the problem: If certificate revocation worked and was reliable this type of setup would not be needed and would actually make you less secure (for the reasons you stated).

However the reality on the ground is that certificate revocation is somewhere between unreliable and damn right broken. Right now the primary way certificates are revoked is via operating system updates or via browser updates (e.g. Chrome has a revocation list they update semi-regularly).

Covered somewhat here:

https://www.imperialviolet.org/2012/02/05/crlsets.html

So while adding an oracle does definitely increase your attack surface, at least you are never dependant on certificate revocation for your ultimate security.

I guess it really boils down to this: What do you trust more, certificate revocation or your own ability to secure the oracle? For me the answer is a no brainer, simply because I distrust certificate revocation so much.

roc2• 12 years ago

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

philipwhiuk• 12 years ago

You would think the Federal reserve would just react by increasing the scope of what they have to notify for - seeing as a compromised Cloud Flare server could do something nasty in this scenario.

bkh• 12 years ago

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

kcbanner• 12 years ago

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

jgrahamc8• 12 years ago

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.

Rapzid3• 12 years ago

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.

personZ4• 12 years ago

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.

spacefight4• 12 years ago

Yes - and it's nowhere near "keyless" - it's just that the key is somewhere elseTM.

Rapzid3• 12 years ago

Maybe they should have said "keyless termination"? I can see that as they are still terminating the connection and they don't have the key.

rlpb• 12 years ago

Indeed; what they are doing seems to be pretty much the same thing as any (RSA) hardware crypto device. Except that it's over the Internet instead.

Mawaai• 12 years ago

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

dsl• 12 years ago

CloudFlare has learned their lesson from past experiences and how makes the big media announcement one day with a smaller less publicized announcement later covering the technical details. This prevents reporters from stumbling across a HN thread tearing the "new internet saving technology" apart and reporting on weaknesses or flaws.

jldugger• 12 years ago

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.

bdamm2• 12 years ago

Agreed. They could have just used PKCS11 and claimed the same result.

blibble• 12 years ago

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

spacefight4• 12 years ago

Banks will typically do what the regulations require and then, what the cost of doing it is. Sometimes, that order flips ;)

indutny5• 12 years ago

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• 12 years ago

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.

keyme• 12 years ago

It's a matter of trust. You do trust Intel corp to not place an RF transmitter inside your CPU, right?

praseodym2• 12 years ago

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

jgrahamc8• 12 years ago

What threat are you concerned about?

praseodym2• 12 years ago

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.

spindritf• 12 years ago

You get to see all the credentials, passwords, balances, private information... of banks' customers. This is no doubt an improvement, you may even be more technically capable than the bank itself, but if someone breaches CloudFlare, they can still get everything they would want from hijacking a connection to a bank.

vidarh• 12 years ago

The big deal is that CloudFlare's ability to sign SSL sessions can be yanked with the flip of a switch, with no need to trust CloudFlare.

Of course you still need to trust CloudFlare to let them provide SSL functionality for you in the first place. But often the issue of "do I trust them today?" is separate from "will I still trust them tomorrow? and what happens if I don't?".

E.g. consider if I trust CloudFlare today, but want to be protected in the event that they fail and suffer intrusion. With this service, I could as an emergency just flip a switch (shut down the devices providing the key signing) and instantly disable CloudFlare's ability to accept SSL connections on my behalf, without having to trust that they manage to deal with the intrusion properly.

By allowing me to put less trust in them, I may trust them more, because the ability to counteract misplaced trust is much better.

michaelt• 12 years ago

  The big deal is that CloudFlare's ability to sign SSL
  sessions can be yanked with the flip of a switch, with no
  need to trust CloudFlare.

Sounds like we'll be able to close the stable door within seconds of the horse bolting.

Surely now the federal regulators will let us keep the barn door open?!

vader12• 12 years ago

Indeed.

Imagine an internet user who uses online banking with one of these banks; registered his domains with Namecheap; keeps some bitcoins at Coinbase; pseudonymously frequents Reddit; and posts anonymously at 4chan every now and then.

By merely passively eavesdropping on all traffic from and to your IP address, Cloudflare can build a profile that links your real world identity to all your Reddit posts you thought were anonymous; to the naughty threads you visited on 4chan; to the amount of money in your bank account; and to the domains and bitcoin addresses you own.

This is something that neither your ISP or any of those individual site owners could ever do, and which might even make the NSA a bit jealous. Now consider what Cloudflare could do on your behalf (and make it look like it was you) if, say, a disgruntled employee was actively out to get you.

I'm not at all saying that there is any reason to distrust Cloudflare, but is it not an enormous amount of power to place in the hands of one entity? Even more so than we do with parties like Google or Facebook, which get immensely more scrutinized over it?

astrange• 12 years ago

4chan's posting API is actually not (as of this very second) behind Cloudflare.

m1keil• 12 years ago

previously they had your private key, so they could see unencrypted plaintext anyway.

indutny5• 12 years ago

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

haberman3• 12 years ago

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?

peterwwillis3• 12 years ago

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

mzs• 12 years ago

Though Fedor isn't just some complete stranger online.

kyledrake• 12 years ago

indutny is no stranger. Highly respected coder.

indutny5• 12 years ago

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Here is an example of how it could be used (in my TLS terminator):

https://github.com/indutny/bud/compare/master...feature/asyn...

Basically, if you have ever used async SSL API, you should be aware of things like:

    SSL_ERROR_WANT_READ
    SSL_ERROR_WANT_WRITE

In addition to these two, my patch adds:

    SSL_ERROR_WANT_SIGN
    SSL_ERROR_WANT_RSA_DECRYPT

If one of these is returned - you may get the data that should be signed/decrypted with:

    SSL_get_key_ex_data()
    SSL_get_key_ex_len()

Get the key type (in case of SIGN):

    SSL_get_key_ex_type()
    // Returns EVP_PKEY_RSA, EVP_PKEY_ECC

And get signature digest nid with:

    SSL_get_key_ex_md()

Please be aware of the fact that `md` could be `NID_md5_sha1`, take a look at bud's code to figure out what should be done in this case (basically, you'll need to use raw `RSA_decrypt_private()`).

After performing sign/decrypt (which could happen in other thread, or on a different server) you should call:

    SSL_supply_key_ex()

to supply the result and continue handshake process. At this point `SSL_read()`/`SSL_write()` will start returning proper values.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iQIcBAEBAgAGBQJUG2D2AAoJENcGPM4Zt+iQJdoQAKZxbcGpzHFktSbU3uDocy3R fywWmqkYnoJ5jWF3xn4Excv4dAGhMfb/7tm9nt9zyV8g0Qsu8ChqWTl+kgK+hj9o mV+3jhqPDWR2VhmAC3J5ZsCpNm3IW/iNgGiU+u/k9N2i0WHjYSoTHM/NooN5GIu2 KKhNXPw1Y05yxOZWmbUInMl/uscGWDtzylRNyJpfLFFu3JDQy1sBTKD6UAZC5ERY 7LUZ1TqVdk1DPY3Tf/j4IaB9Ds9teGLGj63J8upJhDjWHibFzV5bx6X+FjknUB9M xaebV4yfHZNRHseBu2ZqTQ2f2MNnXVisdzJRX6oyYeyq872MsJjAFhbFhFTi0sTI T8Y9n8cjuctbn+zTISVyVqEEBl8udWTY1t14SJ9lNcdU3xAf9OzEBVdORpUDqFl+ zteRC145o7gs7mEtJjyBpy8mhXB3mc13ZkC2qaJIyqkqAPODu/xlqCga7oaogHNy Q2wy0HUeX69Ra0ada3TcJQgB14qESj3Uvq1hcgFk7SEXBxkU5NJ2OcItvU1+emd7 hRlQvDqiiQcK9WgsdOIKZpovtT3FswhsIy0Tv77Nx9PY04urOTEgmhPJHveCJOQq i0apvI09YgimXs4Sd5h3rs9TsKrDtG0BG0jM1zfo5zbcKE2IbMpmzOc84MxkwUSl tPV48uw46UVpu4zOOByM =zJGs -----END PGP SIGNATURE-----

sarciszewski7• 12 years ago

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

diafygi2• 12 years ago

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

jgrahamc8• 12 years ago

No.

sarciszewski7• 12 years ago

Is it related? ;)

mhandley• 12 years ago

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.

Xylakant• 12 years ago

Since key revocation is fundamentally broken it's the difference between having a limited time period where you're exposed and being exposed until the cert actually expires.

chetanahuja2• 12 years ago

"Since key revocation is fundamentally broken"

Do you mean SSL key revocation in general broken or in this proposed solution by cloudflare. If it's the former, would you care to elaborate how it's broken?

tokenizerrr2• 12 years ago

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.

theintern• 12 years ago

That's how I read it too. You can gain control of a session, but the private key should remain safe. I could be wrong though.

sp332• 12 years ago

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

makomk3• 12 years ago

Actually, thanks to session tickets, they can continue to impersonate the bank to existing users for potentially quite a while after Cloudflare lock them out.

seccess• 12 years ago

This. SSL/TLS can ensure perfect forward secrecy when the private key is compromised, as long as the session information is ephemeral. With session tickets, compromise of the key used to create the tickets means every session created under that key can be compromised, regardless of whether the private key is lost. See https://www.imperialviolet.org/2013/06/27/botchingpfs.html for a great discussion of this.

tetrep• 12 years ago

how so? forward secrecy is public key crypto, the private key never leaves the oracle so all cloudfare needs to do is refuse requests made with the public key. ideally the oracle would block it as well, but having cloudfare do everything means minimal administration for their clients.

windexh8er2• 12 years ago

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• 12 years ago

That's Hardware Security Module.

windexh8er2• 12 years ago

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

bdamm2• 12 years ago

HSM technology and their vendors are doing fine and will continue to do well in the cloud. Physical control of identity keys is actually one of the few ways to link the cyber world with the physical world, and proxying key access is certainly one reasonable way to do it.

xorcist6• 12 years ago

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.

jgrahamc8• 12 years ago

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

zameericle• 12 years ago

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

sarciszewski7• 12 years ago

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.

delinka2• 12 years ago

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

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• 12 years ago

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

sarciszewski7• 12 years ago

Attempting to solve a cryptographic attack with a configuration policy doesn't sound like a wise move.

jonknee3• 12 years ago

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.

grittygrease2• 12 years ago

The key server only accepts mutually authenticated TLS 1.2 connections with a strong cipher suite. We also require both certificates to be signed by CloudFlare's internal Certificate Authority.

herge• 12 years ago

What stops them from using SSL between CloudFlare and the 'oracle'?

delinka2• 12 years ago

Not a thing. Not exactly an interesting implementation, but then it doesn't have to be-- normal SSL should work just fine.

That said, silliness can lead to a recursive/"turtles all the way down" kind of issue.

zobzu2• 12 years ago

one of the issues with that is latency, i wonder how they work around that. or maybe they just dont care for latency

agwa4• 12 years ago

The handshake is probably not much slower than it would be if the web browser were connecting directly to the bank, since there is only one round trip with the key server per handshake, and the latency between Cloudflare and web browsers tends to be pretty low since Cloudflare has so many POPs.

zmanian• 12 years ago

A nice thing about supporting a key oracle is that you keep the key material out of the process handling TLS. In the case of Heartbleed like bugs, this would protect against the loss of keys.

_pmf_• 12 years ago

Are we reinventing Kerberos again?

mback2k• 12 years ago

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

ilaksh4• 12 years ago

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.

ilaksh4• 12 years ago

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.

wmf• 12 years ago

Almost every sentence of your comment contains non-obvious yet unsupported conclusions. I don't think a HN comment is the appropriate venue for your thinking; maybe a 20-page paper would be better.

jessaustin• 12 years ago

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

nullymcnull• 12 years ago

If it is not patently obvious to you that broad ramblings about how "human lives have value", "lethal force is not an acceptable way to resolve conflict", "James Bond fantasy" to "primitive Social Darwinism" (and on and on) have next to no relevance to a discussion about Cloudflare's Keyless SSL implementation, of all things, then I don't know how anybody could ever get through to you to help you understand.

vader12• 12 years ago

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• 12 years ago

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.

willvarfar2• 12 years ago

It seems harsh to call it theatre, and I expect all cloud services will adopt it.

It means people can use a cloud service without giving them private keys. This seems much better than giving them keys.

I too was hoping there would be some clever math to make it so some part of the conversation between client and back end was an encrypted tunnel that cloudfare can route but not read. This doesn't seem to be the case.

But all the same, however small a step, its not theatre.

dfc• 12 years ago

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

otterley2• 12 years ago

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• 12 years ago

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.

otterley2• 12 years ago

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.

agwa4• 12 years ago

Cloudflare already has a heavy dependence on the origin server being up, particularly for non-cacheable dynamic websites, so adding a key server doesn't really change anything. It has always been critical that you keep the address of your origin server, and now your key server, secret so that it's not targeted directly by DDoS attackers.

EGreg2• 12 years ago

CloudFlare can have a private connection to your private key infrastructure.

rdl2• 12 years ago

True -- if the keyless server is down, we can't even complete the ssl handshake for new clients.

The keyserver is stateless, so you can have a bunch of keyservers (which don't need to be particularly near your own infrastructure) to deal with this, though.

There's also session caching (tickets or session id), so this only affects people who haven't connected to a cloudflare site recently.

It IS an issue, but it's not that hard to deal with.

EGreg2• 12 years ago

Wow, what a great read!

lucb1e3• 12 years ago

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.

personZ4• 12 years ago

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.

willvarfar2• 12 years ago

It is very obvious... In hindsight?

ChuckMcM• 12 years ago

I think the exaggeration is because its a sales pitch, but it illustrates an important concept -- doing something "known" but in a generic way can be more valuable than having a proprietary solution. Of course someone could come up and offer a 'Cloudflare' box that just does key sequestration and sell that.

And while I think banks and others will find this useful, its even more useful if I can do it from a far away place. When you create an SSL connection in Europe to a west coast server there are a number of round trips. If those can be avoided you can cut the latency of the transaction. That is a good thing too.

Perseids3• 12 years ago

Generally the key you would give them is for, and limited to, the resources that they cache/reverse proxy

That got me wondering: Why don't attackers then only DOS the dynamic pages? Those that can't be migrated easily, like the login?

mikeleeorg• 12 years ago

Thanks for explaining this. I would also love to read your opinion. Would you be willing to share it in a separate comment?

(And hopefully it doesn't incur any downvotes and readers understand it is just an opinion.)

lucb1e3• 12 years ago

Sure. TL;DR: I think it's mostly useless. From an engineering perspective this is a creative way to circumvent management's requirements ("our encryption keys must be kept on premises"), but otherwise I don't see the value.

Let's first see what the problem is with the old method, storing the private key on the Cloudflare server:

1. Cloudflare can read all traffic.

2. Cloudflare can read traffic they can intercept, even if it's not directed towards their server. Think public WiFi access points.

3. Anyone able to break into Cloudflare, physically or technically (or legally, hello NSA!), has the same capabilities.

Number two is a bit far-fetched without taking number 3 into account, except that there might be national security letters to obtain the private key, after which government agencies can use their own intercepts. Still slightly far-fetched, but a plausible concern if you're the bank that the next Edward Snowden just happened to use (Lavabit's private key needed to be handed over, disregarding all other customers' privacy).

Now we implement this new system, where you can only obtain the decryption for the encrypted session key (as sent by the client, e.g. a browser).

1. Cloudflare can still read all traffic.

2. They can no longer passively read any traffic, or hand over private keys to law enforcement. However, the encrypted session keys could still be queried at the keyserver. The keyserver would need to actively maintain a blacklist of session keys that are not in use at Cloudflare, e.g. by having webservers send them as they were used, and raise alarm flags if a false one comes up. But I'd need to work out this attack scenario further to be sure there is no loophole that could make it look like Cloudflare traffic even if it's direct (but intercepted by whomever) traffic. I think something like that might be possible, but I'd need to work it out to be sure.

3. Anyone hacking Cloudflare is now limited in the same way Cloudflare is (so the same as point number two).

So far the security concerns. Now as for speed and DDoS mitigation...

- Cloudflare now needs to query an external server (if it's in their datacenter, it can be pretty much considered under their control) for every https connection. Assuming there is a direct peering connection to a datacenter next-door, this would only be a couple of milliseconds in network latency, but so is DNS and building a TCP connection and fetching a page... it all adds up and in the end you notice that pages need to load, even if only for a sec.

- The SSL termination point is now nearer to the client, as Cloudflare has datacenters all around the world. You could in theory build the keyservers next to many of them, but then you're rolling a CDN for a CDN (a delivery network of content (keys) for a content delivery network (cloudflare)). Perhaps not a bad idea, but it just sounds a bit silly. All things considered, at best the connection gets only a tiny bit slower.

- Cloudflare is still useful for mitigating attacks, just like with normal http traffic. I mean, they can read the data, so it's more or less the same as with unencrypted http. The difference is the keyserver: they might run over capacity. Luckily you can now solve that problem by throwing money at it (you can deploy more keyservers, Cloudflare already has enough front-end servers to handle the requests). So it's now a money issue, not a technical one, which is how you want things to be.

- Session reuse makes this somewhat less of a pain, as the keyserver need not be queried for repeated https connections. We'd need to see numbers to know how much of a win this is, though. In any case, it's never faster than not having the keyserver.

So in this area it's still a win, but so was handing over your keys. Having keyservers makes it slightly less of a win.

---

In conclusion, you have three options:

- Don't use Cloudflare. Fastest website, but risk of DDoS.

- Old-style Cloudflare https setup: handing over your keys. DDoS risk mitigated.

- New technique: providing keyservers. Slightly slower than the old style, but with a tiny security advantage that might help with either management or rare kinds of high-profile attacks.

Disclaimer: I'm not a Cloudflare tech, I'm a software engineering and information security student (and a major nerd in general, I might add). I might be missing something, but many other comments seem to be saying similar things.

kansface• 12 years ago

Is this not subject to side channel attacks (for recovering the key)? Also, whats the point if you are letting a third party read all of your traffic at any rate?

pyre2• 12 years ago

For starters, you can move away from CloudFlare, and you don't need to worry about issuing a new key-pair (b/c CloudFlare, or a unscrupulous CloudFlare employee could use the old private key to impersonate your site).

yk• 12 years ago

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

yusyusyus• 12 years ago

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

agwa4• 12 years ago

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.

bjornsing• 12 years ago

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.

general_failure• 12 years ago

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

zaroth2• 12 years ago

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

https://www.google.com/patents/US8782774

ivanr2• 12 years ago

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

zaroth2• 12 years ago

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.

ambrop7• 12 years ago

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• 12 years ago

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.

liricooli• 12 years ago

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

Announcing Keyless SSL

Related Stories