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.
The problem that Keyless SSL is solving is the need for a client to hand over their SSL keys to Cloudflare in order to use Cloudflare's services.
It eliminates the risk that the key will be stolen from Cloudflare and used by the Bad Guys to set up a fake website to steal everyone's credentials.
You might not perceive how big the benefit of this is but you're not the target market. I used to handle the SSL encryption keys (and server security) for the online trading systems of a global investment bank. In my opinion, not having to hand over the SSL keys removes a significant obstacle to banks using Cloudflare's services.
Yes, Cloudflare will still be able to read and, in theory alter, the data flowing between the end-user and the client (I would not be surprised if a future enhancement to this mechanism enabled some kind of hashing/signing of the HTTP requests/responses, such that any attempt by Cloudflare to alter the content would be obvious) but that is an entirely different risk than the risk of your SSL keys being stolen.
They can manipulate traffic, but so can the bank's operations division. The fact that Cloudflare is a different organization makes contractual agreements much more important, but as long as they are in proper order the difference shouldn't be of importance to the end user.
This is something that I spent a lot of time on a few years ago.
Some of the HTTP accelerator servers I ran were in countries or sites that were more problematic than others, so it was desirable to not locate SSL keys on them. Instead of handling HTTP, the servers would become a TCP level proxy, and forward resp / req packets between a server with the SSL key and the client.
The biggest hurdle is that without being able to decrypt the incoming SSL, you can't know anything about the HTTP request -- including hostname or path. So you have to forward all of your received traffic to the same place, and you can only vary the destination based on the source IP that receives it.
IPs are limited. There is no way that Cloudflare could have even 1 IP for each of their customers in each of their sites around the world, it simply cannot be done.
There is lots of other common functionality that you lose (edge caching, cookie routing, etc.) but the inability to route at layer 7 is the big one.
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.
The Keyless SSL server is open source and available on GitHub - https://github.com/cloudflare/keyless - although I'm wondering if its dependence on OpenSSL was a good choice.
My guess is that the customer for whom they developed this has crypto-acceleration hardware that is supported by OpenSSL. Also, this is only doing the actual crypto operations, not running the whole SSL protocol.
Edit: I guess it's also exposing SSL publicly for talking to CloudFlare, which is I guess why they suggested IP firewalling as well (in case of another HeartBleed).
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"?
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.
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?
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.
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.
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?
"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."
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.
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:
From what I understand, the keys stay the same - this is the whole point of this approach. So it's not a "new service". I agree that SHA1 should be deprecated ASAP though.
[+] [-] vader1|11 years ago|reply
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.
[+] [-] jackgavigan|11 years ago|reply
It eliminates the risk that the key will be stolen from Cloudflare and used by the Bad Guys to set up a fake website to steal everyone's credentials.
You might not perceive how big the benefit of this is but you're not the target market. I used to handle the SSL encryption keys (and server security) for the online trading systems of a global investment bank. In my opinion, not having to hand over the SSL keys removes a significant obstacle to banks using Cloudflare's services.
Yes, Cloudflare will still be able to read and, in theory alter, the data flowing between the end-user and the client (I would not be surprised if a future enhancement to this mechanism enabled some kind of hashing/signing of the HTTP requests/responses, such that any attempt by Cloudflare to alter the content would be obvious) but that is an entirely different risk than the risk of your SSL keys being stolen.
[+] [-] jgrahamc|11 years ago|reply
[+] [-] xorcist|11 years ago|reply
[+] [-] skuhn|11 years ago|reply
Some of the HTTP accelerator servers I ran were in countries or sites that were more problematic than others, so it was desirable to not locate SSL keys on them. Instead of handling HTTP, the servers would become a TCP level proxy, and forward resp / req packets between a server with the SSL key and the client.
The biggest hurdle is that without being able to decrypt the incoming SSL, you can't know anything about the HTTP request -- including hostname or path. So you have to forward all of your received traffic to the same place, and you can only vary the destination based on the source IP that receives it.
IPs are limited. There is no way that Cloudflare could have even 1 IP for each of their customers in each of their sites around the world, it simply cannot be done.
There is lots of other common functionality that you lose (edge caching, cookie routing, etc.) but the inability to route at layer 7 is the big one.
[+] [-] justinsb|11 years ago|reply
Good improvements, and session resumption is important to implement, but nothing groundbreaking.
[+] [-] fathom108|11 years ago|reply
http://en.wikipedia.org/wiki/Homomorphic_encryption
[+] [-] alexwilliamsca|11 years ago|reply
[+] [-] pricechild|11 years ago|reply
[+] [-] justinsb|11 years ago|reply
Edit: I guess it's also exposing SSL publicly for talking to CloudFlare, which is I guess why they suggested IP firewalling as well (in case of another HeartBleed).
And it's only a reference implementation!
[+] [-] corobo|11 years ago|reply
[+] [-] bifel|11 years ago|reply
[+] [-] wsh|11 years ago|reply
[+] [-] snowwrestler|11 years ago|reply
[+] [-] yalogin|11 years ago|reply
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|11 years ago|reply
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|11 years ago|reply
[+] [-] spindritf|11 years ago|reply
BTW I probably should have asked yesterday but which CloudFlare plans will include the keyless feature?
[+] [-] ehPReth|11 years ago|reply
[+] [-] kisielk|11 years ago|reply
"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."
[+] [-] mrfusion|11 years ago|reply
[+] [-] peterwaller|11 years ago|reply
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.
[+] [-] higherpurpose|11 years ago|reply
[+] [-] rakoo|11 years ago|reply
From the bank's point of view, where we can say that Keyless SSL is a new product, only 2 cipher suites are allowed:
which, as you can see, don't include sha1.[+] [-] jgrahamc|11 years ago|reply
[+] [-] annnnd|11 years ago|reply