Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keyless SSL: The Nitty Gritty Technical Details

blog.cloudflare.com

Post reply on HN
Print view View original

31–40 of 69 posts

Re: Keyless SSL: The Nitty Gritty Technical Details

#31

Post by peterwaller »

mrfusion wrote: post #30
peterwaller wrote: post #29

Earlier quoted context omitted.

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…

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?

Cloudflare probably is easier than running your own servers and configuring them correctly - I don't know since I haven't used them myself.

But it sounds like you're not very familiar with the importance of the private key. If anyone else other than the bank obtains the bank's private key, the bank would consider that a serious failure, since it means others could impersonate them. The whole point is that you shouldn't give your private key to anyone else, and that without that key, others can't impersonate you.

This "keyless SSL" scheme allows the bank to set up an entity it controls which knows the key. This entity delegates to cloudflare the ability to pretend to be the bank on a request-by-request basis, without divulging the key to anyone. If cloudflare gets compromised, the bank can stop that delegation on demand, the compromise is closed and the key is kept safe.

Re: Keyless SSL: The Nitty Gritty Technical Details

#32

Post by icebraining »

mrfusion wrote: post #30
peterwaller wrote: post #29

Earlier quoted context omitted.

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…

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?

To serve SSL for your domain, Cloudflare needs a certificate for your domain issued by an accepted CA, which someone needs to buy.

The only way for them to set that up would be to become a CA, get browsers to accept their master certificate and then issue their own certs for their clients.

Re: Keyless SSL: The Nitty Gritty Technical Details

#34

Post by josephlord »

pricechild wrote: post #33
alexwilliamsca wrote: post #13

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.

Open source but a rather restrictive license!

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

Also note the patent mentioned in yesterday's discussion.

Re: Keyless SSL: The Nitty Gritty Technical Details

#35

Post by peterwwillis »

justinsb wrote: post #21
alexwilliamsca wrote: post #13

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). And it's only a reference implementation!

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.

Re: Keyless SSL: The Nitty Gritty Technical Details

#36

Post by ianlevesque »

icebraining wrote: post #32
mrfusion wrote: post #30

Earlier quoted context omitted.

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?

To serve SSL for your domain, Cloudflare needs a certificate for your domain issued by an accepted CA, which someone needs to buy. The only way for them to set that up would be to become a CA, get browsers to accept their master certificate and then issue their own certs for their clients.

They actually do offer a service where they proxy your plain-text HTTP to end users as HTTPS and provide a certificate. It's extremely convenient.

Re: Keyless SSL: The Nitty Gritty Technical Details

#38

Post by infogulch »

peterwwillis wrote: post #35
justinsb wrote: post #21

Earlier quoted context omitted.

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!

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…

What? Increased attack surface? For the people that this matters, the alternative to this service is running your own https web server, where the server with the keys in its' memory is also running server apps that directly interface with the outside world, or at the very least a proxy through which all traffic is funneled.

This system reduces the attack surface to the minimum possible: a single oracle that takes encrypted data and returns it decrypted, all secured with pinned, internally signed client certificates where all connections are coming from a trusted partner and where the TLS security can't be downgraded.

To me, this seems like the maximum reduction in attack surface that is theoretically possible.

Re: Keyless SSL: The Nitty Gritty Technical Details

#39

Post by kisielk »

ehPReth wrote: post #37

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

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

Re: Keyless SSL: The Nitty Gritty Technical Details

#40

Post by peterwwillis »

infogulch wrote: post #38
peterwwillis wrote: post #35

Earlier quoted context omitted.

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…

What? Increased attack surface? For the people that this matters, the alternative to this service is running your own https web server, where the server with the keys in its' memory is also running server apps that directly interface with the outside world, or at the very least a proxy through which all traffic is funneled. This system reduces the attack surface to the minimum possible: a single oracle that takes enc…

I'm talking about DDoS attack surface, not private key security attack surface. If you want DDoS protection, this scheme is less reliable than the alternative (having CloudFlare host the private keys).

To get the most secure private key security, a system like this would be the least attack surface only if the keyserver is connecting to the http server. By having the http server connect to the keyserver you expose the keyserver to attack, no matter what protections [like IP whitelisting] you put in place.

Post reply on HN