Live data from Hacker News

Announcing Keyless SSL

blog.cloudflare.com

21–30 of 190 posts

Re: Announcing Keyless SSL

#21

So CloudFlare won't get your private key, but will still get to see unencrypted plaintext for all traffic? Sounds like a huge improvement...

What threat are you concerned about?

I don't really see the security improvement. Actually the key server would be an new attack vector, although one that could be firewalled pretty well.

Re: Announcing Keyless SSL

#23

So CloudFlare won't get your private key, but will still get to see unencrypted plaintext for all traffic? Sounds like a huge improvement...

What threat are you concerned about?

You get to see all the credentials, passwords, balances, private information... of banks' customers. This is no doubt an improvement, you may even be more technically capable than the bank itself, but if someone breaches CloudFlare, they can still get everything they would want from hijacking a connection to a bank.

Re: Announcing Keyless SSL

#24

Earlier quoted context omitted.

What threat are you concerned about?

I don't really see the security improvement. Actually the key server would be an new attack vector, although one that could be firewalled pretty well.

Using CloudFlare implicitly requires trusting CloudFlare.

With this, CloudFlare cannot impersonate you without your endpoint's active consent. As soon as you terminate the service that solves this puzzle for CF, they cannot impersonate you any longer.

So, yes, it is better. Maybe not "great" if your threat model includes CF getting 0wned, but definitely better than giving over your RSA key. ;)

Re: Announcing Keyless SSL

#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. They can do this until Cloudfare notices and closes the security hole.

It's not clear that the difference is all that great in reality, as most of the damage will be done in the first 24 hours of either compromise.

Re: Announcing Keyless SSL

#27

Earlier quoted context omitted.

What threat are you concerned about?

I don't really see the security improvement. Actually the key server would be an new attack vector, although one that could be firewalled pretty well.

It is a huge improvement. Nobody can impersonate the bank without the bank's cooperation. When cooperation ends, so does the ability to impersonate.

This is not the case with any mechanism that requires you to hand over your keys. Not even issuing a revocation effectively terminates use of a compromised key.

Re: Announcing Keyless SSL

#28
post #2

So the communication between Cloudflare and the actual SSL key holder is secured by… what? Another key? In that case, any compromise of Cloudflare’s key is the same as a compromise of the original SSL key (at least in the short term).

Yes, I've seen designs for this sort of thing. It's super scary, because you're essentially offering a decryption oracle with your private key to the Internet. It's authenticated, sure, but even still you've actually increased your attack surface.

A compromise of an SSL terminator, or the ability to pretend to be one, gives the same capabilities as a compromise of the oracle itself. The advantage you get is that only the last requires you to revoke and reissue the key when you figure it out(in other cases, simply unplug the oracle). That's relatively minor most of the time: an open decryption oracle is already hair-on-fire levels of bad.

I can see why some organizations (for whom this process is unusually expensive) might be interested, but it probably isn't beneficial most of the time.

Re: Announcing Keyless SSL

#29
All other technicalities aside it's rather interesting. From an HSM perspective it either makes that hardware now very useful or very useless.

Think of a large organization - you've been there (or not), there are 30 internal applications with self-signed certificates. Fail. The organization had purchased an HSM, but never really got it deployed because - well, that was too complex and it didn't integrate well with 3rd party network hardware and failed miserably in your *nix web stack.

This could be interesting - and I'm not commenting with regard to the efficacy or security concerns around this, but mainly the workflow simplicity it provides to large organizations who end up in self-signed-cert-hell because HSMs don't interoperate easily in a lot of use cases.

But to my original statement - this is a very good thing or a very bad thing for Thales and the like. The only requirement for an actually certified HSM, really, is certification against some hardware and software standard you have a checkbox to fulfill. Beyond that this would be a killer in the middleground for those who want an HSM like functionality but don't have any requirements to meet other than housing a secure segment where key management can be done in a more controlled manner.

Re: Announcing Keyless SSL

#30
post #7

isn't this completely missing the point, i.e. banks being able to say 'no third parties can see our clients identifying information/balances/etc?' yes, the SSL key doesn't leave the bank, but everything it is protecting is..

It's a matter of trust. You do trust Intel corp to not place an RF transmitter inside your CPU, right?
Post reply on HN