Hacker News Reader

Comment by jgrahamc | Hacker News Reader

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.

View on HN

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?

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

If you have access to a machine, why would you ever look for a key on disk instead of in memory?

There are different levels of "accessing a machine", and some of them might not give you access to the memory area where the key is stored.

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

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.

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?

Reply on news.ycombinator.com