Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 today, but want to be protected in the event that they fail and suffer intrusion. With this service, I could as an emergency just flip a switch (shut down the devices providing the key signing) and instantly disable CloudFlare's ability to accept SSL connections on my behalf, without having to trust that they manage to deal with the intrusion properly.

By allowing me to put less trust in them, I may trust them more, because the ability to counteract misplaced trust is much better.


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


They're worried about the other 5 million horses in there.

You always have to trust some server with the plaintext, unless you want a barn that has no door at all.

CloudFlare practices good security. This makes the marginal risk from moving sites onto their servers minimal or even negative, since you only have to worry about the current good security and not CloudFlare-in-six-years security.


Indeed.

Imagine an internet user who uses online banking with one of these banks; registered his domains with Namecheap; keeps some bitcoins at Coinbase; pseudonymously frequents Reddit; and posts anonymously at 4chan every now and then.

By merely passively eavesdropping on all traffic from and to your IP address, Cloudflare can build a profile that links your real world identity to all your Reddit posts you thought were anonymous; to the naughty threads you visited on 4chan; to the amount of money in your bank account; and to the domains and bitcoin addresses you own.

This is something that neither your ISP or any of those individual site owners could ever do, and which might even make the NSA a bit jealous. Now consider what Cloudflare could do on your behalf (and make it look like it was you) if, say, a disgruntled employee was actively out to get you.

I'm not at all saying that there is any reason to distrust Cloudflare, but is it not an enormous amount of power to place in the hands of one entity? Even more so than we do with parties like Google or Facebook, which get immensely more scrutinized over it?


4chan's posting API is actually not (as of this very second) behind Cloudflare.


What threat are you concerned about?


You get to see all the credentials, passwords, balances, private information... of banks' customers. This is no doubt an improvement, you may even be more technically capable than the bank itself, but if someone breaches CloudFlare, they can still get everything they would want from hijacking a connection to a bank.


I don't really see the security improvement. Actually the key server would be an new attack vector, although one that could be firewalled pretty well.


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.


I think "It's clearly worse than doing nothing" is from a purely security perspective. This opens up a larger attack surface, so it's worse in terms of security. But it's better than doing nothing from a business perspective, since it allows for better performance and better handling of DDOS attacks. It's a comprimise. Potentially it is slightly worse in security, but it is much better for performance and uptime.


I think the parent means the key server the bank exposes to CF is a new attack surface. If an attacker could impersonate CF and connect to the key server, they too could authenticate connections as the bank without having the key.


It is a huge improvement. Nobody can impersonate the bank without the bank's cooperation. When cooperation ends, so does the ability to impersonate.

This is not the case with any mechanism that requires you to hand over your keys. Not even issuing a revocation effectively terminates use of a compromised key.


There is no practical improvement here.

What does it matter security-wise if the HSM module (which is what banks use) physically sits on Cloudflare premises or off Cloudflare premises? It's still connected to the same equipment.

It does matter for a variety of other reasons, for example what security clearances are required to work there, but it does not matter much for security.


Now cloudflare employees will have no possible access to the private key, nor do intruders who break into the cloudflare servers. This keeps the bank in full control of who has access to the key, they can stop responding to signing requests at any time and then keep trusting the key on their own servers in the future.


Cloudflare employees will have no access to the key inside a HSM even if it colocated on their premises. That's why you use them.

Please summarize the differences between this protocol and PKCS instead of downvoting.


Without a system like this, you would require many HSMs physically co-located with every server around the world, you would be trusting entirely in the ability of the HSM to withstand prolonged physical attack/analysis by a highly-resourced adversary (I'd consider this security suicide), and you would still not have the ability for the bank to cut off impersonation at any moment.

I have, incidentally, downvoted your comment, because you are complaining about downvotes. Don't do that.


A HSM does not need to be physically attached to "every server around the world". This is what they've built here, yet another network attached HSM, but not by following the standard PKCS protocols.

(On the subject of HSM physical attacks: That's another issue altogether, and does not stop at the HSM. But normally that's not an attack you defend against, because you have the relevant contractual obligations against your infrastructure provider.)

I promise not to ask about downvotes again. But the question was honest; if I'm wrong I want to know it.


If there's an established "correct" solution to this problem, why hasn't anyone pointed to it directly, and why didn't the banks use it?

Could you point to some credible expert commentary (as opposed to anonymous noise on HN) describing why what CloudFlare has done here is wrong?


Why do you think banks don't use HSMs? They do. They are off the shelf products. If it's the "correct" solution to your problems depends on what your problem actually is.

In this case Cloudflare apparently thought it was the right solution in theory but developed their own instead of using existing products and/or standards. I don't know the rationale for this, but I'd be interesting in knowing more, as you can read in my comment above.

I don't know why I should point out that Cloudflare did the wrong thing. Perhaps you are confusing me with someone else?

What I did say is that the alternative to the described solution is to use a HSM, and that their solution should offer equivalent security.


You said "There is no practical improvement here.".

If CloudFlare has not done something wrong, then why did you say that?

Before you answer that question, remember: A hypothetical solution is not a practical solution. A practical solution is always a practical improvement over the case where there was no existing practical solution offered.

And before you say "They should have used HSMs", remember: CloudFlare has made it clear that HSMs being under their control was simply not an option. It was clear in their first blog post, and just for good measure, it was made absolutely explicit in an interview with Ars[0] where CloudFlare's CEO said "there’s no vault we can ever build that they’ll trust us with their SSL keys".

So, how is there no practical improvement?

[0] http://arstechnica.com/information-technology/2014/09/in-dep...


That was in response to: "It is a huge improvement. Nobody can impersonate the bank without the bank's cooperation."

And that is not true. The alternative is not to let other organizations impersonate you without your cooperation. That is very clear from the article. Storing plaintext keys with Cloudflare was never on the table. That's not why they built it.

There reasons to why Cloudflare built their own, probably good ones because Cloudflare employs some talented people, and I would think they have to do with the scale Cloudflare operates at.

Network attached HSMs are off the shelf devices. If you've worked with PKI, you've seen them. And that is what they would have went with if they hadn't built this. If it was right or wrong to go with a home-grown HSM instead of an off the shelf one is not something I could possibly know -- but I know it's not a "huge improvement in security" to build your own. The fact that is offers comparable security is probably why the bank chose it.

If there is one thing to take away from the article, it should be: Don't invent your own security protocols. Buy off the shelf devices. If you really need to build your own, this is how.


previously they had your private key, so they could see unencrypted plaintext anyway.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: