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

Announcing Keyless SSL

blog.cloudflare.com

Post reply on HN
Print view View original

91–100 of 190 posts

Re: Announcing Keyless SSL

#91

Post by motoboi »

otterley wrote: post #86

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…

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.

Re: Announcing Keyless SSL

#92

Post by agwa »

otterley wrote: post #86

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…

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.

Re: Announcing Keyless SSL

#93

Post by cbhl »

vader1 wrote: post #84

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…

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.

Re: Announcing Keyless SSL

#94

Post by agwa »

zobzu wrote: post #85
delinka wrote: post #60

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

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

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.

Re: Announcing Keyless SSL

#95

Post by otterley »

motoboi wrote: post #91
otterley wrote: post #86

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…

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.

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.

Re: Announcing Keyless SSL

#97

Post by makomk »

seccess wrote: post #81
makomk wrote: post #37

Earlier quoted context omitted.

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.

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.

As described, this scheme doesn't provide forward secrecy either. Anyone who can make requests to the key server can decrypt any past session made using the same SSL private key.

Re: Announcing Keyless SSL

#98

Post by jonknee »

otterley wrote: post #95
motoboi wrote: post #91

Earlier quoted context omitted.

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.

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.

In the use case for keyless SSL the caching is pretty useless. Banks (what the article described as the reason this was created) are interactive. They want CloudFare to block the DDOS while letting their customers through. The DDOS attackers aren't firing legit requests (sign-in attempts or whatever) and would never make it through to the SSL handshake.

Re: Announcing Keyless SSL

#99

Post by EGreg »

otterley wrote: post #86

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…

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

Re: Announcing Keyless SSL

#100

Post by jonknee »

davis_m wrote: post #64
delinka wrote: post #60

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

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

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.
Post reply on HN