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

61–70 of 190 posts

Re: Announcing Keyless SSL

#61

Post by DEinspanjer »

Someone1234 wrote: post #52
amalcon wrote: post #28

Earlier quoted context omitted.

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

Beyond the brokenness of certificate revocation, just the simple fact that a financial institution in the US must formally notify the Federal Reserve if any of their private SSL keys are compromised is a huge factor that is better mitigated by this strategy.

To me, the biggest question is whether they can keep the oracle highly available even in the face of a DDoS. It still seems like the weakest link, just slightly more difficult for the attacker to target since they don't have a publicly advertised direct connection to it.

Re: Announcing Keyless SSL

#63

Post by sarciszewski »

zameericle wrote: post #47

Sounds like Elliptic Curve Diffie-Hellman is used between client/server to establish a private key. Not sure how this is new.

At a glance, it appears that the non-ephemeral RSA signature is handled in the network, but the key exchange occurs at the endpoint.

What's new is the whole "edge calls home with a signing request" piece.

Re: Announcing Keyless SSL

#64

Post by davis_m »

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?

Re: Announcing Keyless SSL

#65

Post by grittygrease »

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…

Breaking into a CloudFlare server does not get you this private key. CloudFlare does not keep this authentication key unencrypted on disk.

Re: Announcing Keyless SSL

#66

Post by sarciszewski »

marcosdumay wrote: post #46
sarciszewski wrote: post #24

Earlier quoted context omitted.

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

And that's why regulations make it almost impossible for banks to use CloudFare. But CloudFare sees that as a problem, and makes some effort to create a loophole. You can't claim that this improves the bank clients' security. It's clearly worse than doing nothing.

Think of it as a compromise: You can leverage CloudFlare's CDN to mitigate DDoS and other sorts of nasty attacks AND assure TLS is used with every connection, without giving up your RSA key.

"It's clearly worse than doing nothing." It's not very clear to me. Please explain.

Re: Announcing Keyless SSL

#67

Post by sarciszewski »

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?

Attempting to solve a cryptographic attack with a configuration policy doesn't sound like a wise move.

Re: Announcing Keyless SSL

#68

Post by rurounijones »

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…

I would imagine that that link would be IP Restricted, VPN'd maybe, carefully monitored etc.

Re: Announcing Keyless SSL

#70

Post by ivanr »

eastdakota wrote: post #49
Rapzid wrote: post #34

Earlier quoted context omitted.

Do you guys have a "global" session ticket cache shared amongst endpoints? Or do you ensure the same user gets routed back to the same termination node? I'm quite curious about this.

Session Tickets are shared globally. Session IDs are shared intra-data center (so regionally). The former works with Chrome/Firefox. The latter with all other browsers.

Do you use per-site session ticket keys?
Post reply on HN