Hacker News Reader

Comment by teddyh | Hacker News Reader

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

View on HN

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.

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.

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.

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.

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

It gets a little cumbersome to hedge casual conversation the way attorneys do, but sure, it would have been more accurate to have said:

"might not, under the current rules, which are always subject to change"

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?

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?

Same thought here. And what if that connection breaks? Another single point of failure?

Multiple connections between CloudFlare and the Keyless SSL Server running at the customer site. Connections are reused, pipelined, load balanced etc.

Interesting. Multiple connections AND multiple servers?

Yes.

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.

Key services are used to kickstart the SSL connection, not support it the whole way through (I believe?), so the 'load' is SIGNIFICANTLY less than terminating the entire connection for the whole session.

We don't expect there to be a cap-ex spend need here because we will be offloading most of the SSL processing to our servers (as well as offloading other parts of the web session).

Reply on news.ycombinator.com