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