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

71–80 of 190 posts

Re: Announcing Keyless SSL

#71

Post by grittygrease »

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…

The key server only accepts mutually authenticated TLS 1.2 connections with a strong cipher suite. We also require both certificates to be signed by CloudFlare's internal Certificate Authority.

Re: Announcing Keyless SSL

#72

Post by herge »

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…

What stops them from using SSL between CloudFlare and the 'oracle'?

Re: Announcing Keyless SSL

#73

Post by yxhuvud »

Someone1234 wrote: post #54
jgrahamc wrote: post #13

Earlier quoted context omitted.

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…

It is a heck of a lot easier to revoke one certificate on one oracle you control yourself than to revoke a certificate on every end user though.

Re: Announcing Keyless SSL

#74

Post by philipwhiuk »

roc wrote: post #50
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).

A notable difference is that a compromise of Cloudflare's key wouldn't [edit: might not] require the bank to notify the Federal Reserve. It may be pretty cynical to call that situation a "feature". But I'm sure it came up. And I'm sure they noticed. It certainly wouldn't be the first time "trivial functional difference" translated to "massive legal difference."

You would think the Federal reserve would just react by increasing the scope of what they have to notify for - seeing as a compromised Cloud Flare server could do something nasty in this scenario.

Re: Announcing Keyless SSL

#75

Post by bkh »

roc wrote: post #50
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).

A notable difference is that a compromise of Cloudflare's key wouldn't [edit: might not] require the bank to notify the Federal Reserve. It may be pretty cynical to call that situation a "feature". But I'm sure it came up. And I'm sure they noticed. It certainly wouldn't be the first time "trivial functional difference" translated to "massive legal difference."

You should probably say "might not", because although we know a key compromise would require notification, you'd have to have an actual lawyer tell you if a compromise of CloudFlare would not. Unless the lawyers are on board with this as a solution to the notification problem, the whole solution doesn't do anything (legally).

Re: Announcing Keyless SSL

#76

Post by michaelt »

vidarh wrote: post #42
praseodym wrote: post #14

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

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?!

Re: Announcing Keyless SSL

#78

Post by delinka »

herge wrote: post #72
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…

What stops them from using SSL between CloudFlare and the 'oracle'?

Not a thing. Not exactly an interesting implementation, but then it doesn't have to be-- normal SSL should work just fine.

That said, silliness can lead to a recursive/"turtles all the way down" kind of issue.

Re: Announcing Keyless SSL

#79

Post by JshWright »

Someone1234 wrote: post #54
jgrahamc wrote: post #13

Earlier quoted context omitted.

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…

The mutually authenticated TLS connection between Cloudflare and the oracle uses a certificate that has been signed by Cloudflare's internal CA. When you manage the CA and have influence over both endpoints, revocation can be trusted.

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

You make it sound like that's not a _huge_ win... Which would you rather do, ensure revocation on millions of end user systems, or a handful of systems that are controlled by a party you have a close partnership with?

Re: Announcing Keyless SSL

#80

Post by JshWright »

delinka wrote: post #78
herge wrote: post #72

Earlier quoted context omitted.

What stops them from using SSL between CloudFlare and the 'oracle'?

Not a thing. Not exactly an interesting implementation, but then it doesn't have to be-- normal SSL should work just fine. That said, silliness can lead to a recursive/"turtles all the way down" kind of issue.

Not really. This while dance is necessary because it's (effectively) impossible to revoke certs on millions of end user systems.

It's _far_ easier to handle revocation on a couple trusted endpoints (especially when you own the CA), so 'normal' TLS does the job here just fine. No need for more turtles.

Post reply on HN