Keyless SSL: The Nitty Gritty Technical Details

https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

by jgrahamc • 12 years ago

162 68 12 years ago

blog.cloudflare.com

spindritf• 12 years ago

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?

justinsb2• 12 years ago

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

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

fathom108• 12 years ago

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

http://en.wikipedia.org/wiki/Homomorphic_encryption

vader14• 12 years ago

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.

jgrahamc4• 12 years ago

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

vader14• 12 years ago

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

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

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

dsl2• 12 years ago

Actually thats pretty disingenuous. Most of the attacks CloudFlare prides itself on defending are amplification attacks (NTP and DNS specifically) not DoS attacks within the relevant protocols. Servers that simply forwarded 80 and 443 while dropping everything else sitting on really big pipes is really what people are paying you for today.

xorcist6• 12 years ago

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.

kordless• 12 years ago

It's still based on implicit human trust though.

vader14• 12 years ago

The difference to the end user is that while the bank's operations division can only do this for a single website, Cloudflare can do so for 2 million of them.

jackgavigan2• 12 years ago

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.

mr_brown• 12 years ago

CDNs are used to deliver static, highly cacheable content, like assets, images, media content, stuff that will be delivered to many users. It is very rare that a website serves this type of content under the same domain as the dynamic content (think cdn1.whatnot.com, assets-myapp.com). In fact for applications with a lot of assets this is a must because of domain sharding and to avoid the overhead of sending the cookies on every single request. Since you need a different domain, you can (you don't have to) use a different certificate, so it's not a strech to use a different private key.

Then there are the applications where security is more important than latency - online banking, payment gateways, tax filing. Those applications don't have too much cache-able content so they simply won't benefit from CDNs.

I also don't see how is this faster. Sure, CloudFlare Keyless SSL is faster than serving the content yourself, but sending that packet over the internet is always going to be slower than not. So now I have a slower (compared to the CDN having my key), more complicated option that requires me to run an additional keyserver and doesn't provide me additional security. The only upside of this seems to be good PR.

Depending how sensitive the content is, in fact if I could I would choose to deliver it over plain HTTP and sign it somehow. That would be best of both worlds.

Edit: I admit I totally missed the point about DDoS protection.

skuhn• 12 years ago

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.

higherpurpose• 12 years ago

It's one thing to keep SHA1 in old services, but why do they keep pushing SHA1 into new ones?

annnnd• 12 years ago

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.

jgrahamc4• 12 years ago

What use of SHA-1 are you talking about?

rakoo• 12 years ago

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

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

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

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

xorcist6• 12 years ago

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.

ctz2• 12 years ago

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.

xorcist6• 12 years ago

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

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

alexwilliamsca2• 12 years ago

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.

corobo• 12 years ago

Out of curiosity what would you have used?

alexwilliamsca2• 12 years ago

CyaSSL - http://www.yassl.com/yaSSL/Products-cyassl.html

justinsb2• 12 years ago

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

And it's only a reference implementation!

peterwwillis4• 12 years ago

You've hit on the most dangerous part of this whole scheme: increased attack surface. There is now a much higher likelihood of a successful attack taking down the site, due to the client needing to both open up and harden its keyserver on the internet (i'm presuming they don't have private connections between cloudflare and the customer site).

And obviously if any hole is found in either the client's keyserver or the network or host it runs on, the private key is now at risk. One could argue that the client is much less reliable in terms of hardening their security than CloudFlare is.

In order to reduce the attack surface, the client's keyserver needs to be connecting to CloudFlare, so they don't need to expose a service on the internet and thus an attacker won't know what to try to attack to take down the keyserver.

pricechild• 12 years ago

Open source but a rather restrictive license!

josephlord• 12 years ago

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

Also note the patent mentioned in yesterday's discussion.

mrfusion2• 12 years ago

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

peterwaller2• 12 years ago

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.

mrfusion2• 12 years ago

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

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

ehPReth2• 12 years ago

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

kisielk• 12 years ago

From the article:

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

ehPReth2• 12 years ago

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

bifel2• 12 years ago

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

wsh2• 12 years ago

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.

bifel2• 12 years ago

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

snowwrestler2• 12 years ago

The more people who have a copy of a key, the more chances for a copy to be lost or stolen by a bad guy.

yalogin• 12 years ago

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?

Keyless SSL: The Nitty Gritty Technical Details

Related Stories