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

51–60 of 190 posts

Re: Announcing Keyless SSL

#51

Post by jerf »

peterwwillis wrote: post #41
ch wrote: post #33

Earlier quoted context omitted.

Won't this approach increase the cap-ex investment on the part of the customer, and the complexity to scaling? Do you require the customer to size their key services to some theoretical peak, or can you offload so much of the process that the customer just needs to make a one time investment? (Full disclosure. I work for a competitor, but not on problems like this).

The customer site now is responsible for providing key signing in a highly available fashion. It makes sense they would need to spend more (probably no more than for an hsm) to ensure the connection never goes down. If you can take down the connection from Cloudflare to the customer site, their website goes down.

I would also observe that given the constraint that the customer doesn't want to actually give out their private key (and nobody should be willing to give it out, really...), this is the minimal possible maintenance burden they could possibly incur. Yes, the customer has to do something, but we already take that as a given when we say we won't hand out the private key. If the customer wants to have the responsibility, being able to reduce that cost to the bare mathematical minimum is a big deal.

Re: Announcing Keyless SSL

#52

Post by Someone1234 »

amalcon wrote: post #28
teddyh wrote: 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…

Here's the problem: If certificate revocation worked and was reliable this type of setup would not be needed and would actually make you less secure (for the reasons you stated).

However the reality on the ground is that certificate revocation is somewhere between unreliable and damn right broken. Right now the primary way certificates are revoked is via operating system updates or via browser updates (e.g. Chrome has a revocation list they update semi-regularly).

Covered somewhat here:

https://www.imperialviolet.org/2012/02/05/crlsets.html

So while adding an oracle does definitely increase your attack surface, at least you are never dependant on certificate revocation for your ultimate security.

I guess it really boils down to this: What do you trust more, certificate revocation or your own ability to secure the oracle? For me the answer is a no brainer, simply because I distrust certificate revocation so much.

Re: Announcing Keyless SSL

#53

Post by Mawaai »

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

Re: Announcing Keyless SSL

#54

Post by Someone1234 »

jgrahamc wrote: post #13
teddyh wrote: 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).

The communication between CloudFlare and the Keyless SSL Server at the customer site is mutually authenticated TLS 1.2 with a specific set of cipher suites.

So if someone breaks into a CloudFlare server, can they steal the CloudFlare private key and then make unlimited numbers of requests against the e.g. bank's oracle?

Aren't you now still depending on certificate revocation but have just shifted the problem downstream (it is now the bank's job to revoke you, rather than the user's browser's job).

Or do you yourselves use "Keyless" technology, so that CloudFlare servers contact some CloudFlare oracle so that they can communicate with the bank oracle?

Re: Announcing Keyless SSL

#55

Post by reconbot »

windexh8er wrote: post #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 3r…

That's Hardware Security Module.

Re: Announcing Keyless SSL

#56

Post by bdamm »

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.

Agreed. They could have just used PKCS11 and claimed the same result.

Re: Announcing Keyless SSL

#57

Post by grossvogel »

sarciszewski wrote: post #24
praseodym wrote: post #21

Earlier quoted context omitted.

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

I think the parent means the key server the bank exposes to CF is a new attack surface. If an attacker could impersonate CF and connect to the key server, they too could authenticate connections as the bank without having the key.

Re: Announcing Keyless SSL

#58

Post by windexh8er »

reconbot wrote: post #55
windexh8er wrote: post #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 3r…

That's Hardware Security Module.

HSM = Hardware Security Module, yes, that was implied and my point.

Re: Announcing Keyless SSL

#59

Post by bdamm »

windexh8er wrote: post #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 3r…

HSM technology and their vendors are doing fine and will continue to do well in the cloud. Physical control of identity keys is actually one of the few ways to link the cyber world with the physical world, and proxying key access is certainly one reasonable way to do it.

Re: Announcing Keyless SSL

#60

Post by delinka »

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 algorithm) risks exposure through deduction if an attacker can submit limitless requests. See http://en.wikipedia.org/wiki/Chosen-plaintext_attack

I'm not at all suggesting that CF hasn't thought of this; rather I want to see their mitigation of the risk.

Post reply on HN