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

81–90 of 190 posts

Re: Announcing Keyless SSL

#81

Post by seccess »

makomk wrote: post #37
mhandley wrote: post #26

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. T…

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.

Re: Announcing Keyless SSL

#82

Post by dsl »

Mawaai wrote: post #53
personZ wrote: post #4

After reading the beginning of the piece, I was expected something more...profound. Some deep mathematical breakthrough or something. Instead they separate the actual key signing, delegating it to the customer's device. That's nice and useful, but isn't quite what I was expecting.

"Tomorrow, we'll publish a full post on the nitty, gritty techical details of how, what has come to be called Keyless SSL™, works."

CloudFlare has learned their lesson from past experiences and how makes the big media announcement one day with a smaller less publicized announcement later covering the technical details. This prevents reporters from stumbling across a HN thread tearing the "new internet saving technology" apart and reporting on weaknesses or flaws.

Re: Announcing Keyless SSL

#83

Post by ilaksh »

This is a discussion about cyberwarfare in a literal sense. The technical discussion shouldn't really be separated from the economic, political, social and human health concerns because all of those parts of the system interact deeply and directly.

A goal of total political cooperation or submission leads to economic sanctions leading to serious human health effects leading to defensive denial of service attacks. This accelerates the need to decentralize the financial network systems to make them more robust.

How can we imagine though that even after a complete transition to next generation systems that are ground-up distributed designs (not just stop-gap tweaks like this) that we won't have new types of attacks to deal with.

The starting point is the belief system that provides such fertile ground for conflict. We have to promote the idea that human lives have value and that lethal force is not an acceptable way to resolve conflict.

As long as decision makers are living in a sort of 1960s James Bond fantasy world we will all be subject to the insecurity of that type of world. Its largely built upon a type of primitive Social Darwinism that is still much more prevalent than most will acknowledge.

Its much easier to accept a compartmentalization of these problems and focus on a narrow technical aspect, but that does not integrate nearly enough information.

Re: Announcing Keyless SSL

#84

Post by 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?

Re: Announcing Keyless SSL

#85

Post by zobzu »

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

Re: Announcing Keyless SSL

#86

Post by 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.

Re: Announcing Keyless SSL

#87

Post by kathrinalewis »

To clarify, is this is a separate offering than the lazy loaded certificates that are slated to appear in the next month or so? This new solution is very elegant, so I'm just wondering whether keyless ssl and lazy loaded certificates are two different solutions that we will be able to choose from. Thanks!

Re: Announcing Keyless SSL

#88

Post by chetanahuja »

Xylakant wrote: post #31
mhandley wrote: post #26

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. T…

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.

"Since key revocation is fundamentally broken"

Do you mean SSL key revocation in general broken or in this proposed solution by cloudflare. If it's the former, would you care to elaborate how it's broken?

Re: Announcing Keyless SSL

#89

Post by Dylan16807 »

michaelt wrote: post #76
vidarh wrote: post #42

Earlier quoted context omitted.

The big deal is that CloudFlare's ability to sign SSL sessions can be yanked with the flip of a switch, with no need to trust CloudFlare. Of course you still need to trust CloudFlare to let them provide SSL functionality for you in the first place. But often the issue of "do I trust them today?" is separate from "will I still trust them tomorrow? and what happens if I don't?". E.g. consider if I trust CloudFlare toda…

The big deal is that CloudFlare's ability to sign SSL sessions can be yanked with the flip of a switch, with no need to trust CloudFlare. Sounds like we'll be able to close the stable door within seconds of the horse bolting. Surely now the federal regulators will let us keep the barn door open?!

They're worried about the other 5 million horses in there.

You always have to trust some server with the plaintext, unless you want a barn that has no door at all.

CloudFlare practices good security. This makes the marginal risk from moving sites onto their servers minimal or even negative, since you only have to worry about the current good security and not CloudFlare-in-six-years security.

Re: Announcing Keyless SSL

#90

Post by agwa »

chetanahuja wrote: post #88
Xylakant wrote: post #31

Earlier quoted context omitted.

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.

"Since key revocation is fundamentally broken" Do you mean SSL key revocation in general broken or in this proposed solution by cloudflare. If it's the former, would you care to elaborate how it's broken?

Why the former is broken:

https://www.imperialviolet.org/2014/04/19/revchecking.html

https://www.imperialviolet.org/2014/04/29/revocationagain.ht...

Post reply on HN