Hacker News Reader

Comment by delinka | Hacker News Reader

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.

View on HN

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.

A nice thing about supporting a key oracle is that you keep the key material out of the process handling TLS. In the case of Heartbleed like bugs, this would protect against the loss of keys.

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.

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.

As Google and Yahoo will tell you after they found out the US government broke into their dedicated lines between data centers... No. It must be encrypted at every transfer without exception.

There's a huge difference between passively tapping a fiber optic cable and infiltrating a network to inject malicious traffic. All we've ever seen evidence of is NSA's passive tapping of Google & others.

Wouldn't you want to prevent "passive" tapping? Passive in quotes because depending on what they find people will be killed, tortured, executed, kidnapped, arrested, etc. It's not passive when the NSA scoops up everyone's data and sends it to their spook friends around the world.

We know the NSA targets routers. They have rootkits and remote exploits for them. They can do packet injection or anything else with the traffic passing through routers they take over.

There are more exploited routers than passive taps.

one of the issues with that is latency, i wonder how they work around that. or maybe they just dont care for latency

The handshake is probably not much slower than it would be if the web browser were connecting directly to the bank, since there is only one round trip with the key server per handshake, and the latency between Cloudflare and web browsers tends to be pretty low since Cloudflare has so many POPs.

yes, but over thousand of connections its significant. what was a millisecond or less becomes 20ms. so 20x slower. not sure how much impact this has in real life, but this is one of the issue with this design (also one of the reason is rarely implemented like this but with HSMs instead)

Reply on news.ycombinator.com