Announcing Keyless SSL

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

[mikeleeorg]

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

[kansface]

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?

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

[indutny]

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.

[indutny]

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

[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?

[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

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

[grittygrease]

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.

[zmanian]

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.

[herge]

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

[davis_m]

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

[zobzu]

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

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

[Xylakant]

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.

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

[makomk]

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.

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

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

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

[bdamm]

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.

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

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

[zaroth]

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

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

[ivanr]

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

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

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

[spacefight]

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

[keyme]

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

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

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