51–60 of 80 posts
I would welcome if this incident shone light on possible Cloudflare alternatives. For example, it should be technically doable for DDoS protection service to only initially verify user is not a bot, and then merely tunnel unchanged SSL traffic directly between server and client. Does anyone do this?
So even if the sky didn't fall that's no reason to pretend this wasn't a big deal.
By the nature of the bug, the likelihood of any particular individual having any meaningful exploitable information exposed to somebody in a position to exploit it is astronomically low. So most ordinary people are ignoring it, and justifiably so.
If you're responsible for security for a site that sends traffic through CloudFare, then it's a very big deal for you. You'd better be quick on the trigger to see and react to this stuff, and you'll have to mass-reset sessions at the very least, and possibly reconsider whether you really want to be terminating SSL at CloudFare. Exactly because, while not much has probably been exposed, you will never be able to be sure what was exposed to anyone from random hackers to the whole world, via search engine caches. So a broad reaction is justified.
And of course people who like tech but aren't actually responsible for any sites being served through CloudFare tend to react the most. Even though it's not a big deal if you're already doing all of the standard security precautions, like different passwords everywhere and 2-factor authentication on anything important.
Realistically, this will probably only be exploited by intelligence agencies who have the means of collecting all the data and motivation to do so, and maybe not even them (because they have better ways too). If they do exploit it, the nature of intelligence agencies, of course, means that you typically won't notice any direct impact.
The reason why this caused such a big panic is that while the likelihood of your password being compromised is small, it could have hit anything, and by conventional wisdom, any password/key that _may_ have been exposed, even if the likelihood is small, needs to be considered compromised. Hence, "OMG everything is compromised".
Another reason was probably that it was a really scary wake-up call demonstrating the risks of centralized services. Cloudflare is a Single Point of Failure for a lot of security, but that is easy to push aside until you see it failing.
Realistically (and I'm going to get a lot of flak for saying this) the correct way to handle it is to rotate extremely high-value credentials (think Bitcoin exchangs, administrative access to major services, ...), reset sessions if you're hosting your website on Cloudflare (since session tokens are much more likely to leak than passwords, and the cost of forcing users to re-auth is small especially if your sessions expire regularly anyways), and then call it a day.
In particular, keep in mind that for high-value services, you're hopefully already using 2FA, so even if an attacker did get your password through this, they probably don't have your 2FA token (although Kraken, a Bitcoin exchange, pointed out to their customers that they should re-setup 2FA if originally set up during the vulnerable timeframe, since the key used to derive the 2FA could be compromised).
I deleted my subscription and account with 23andme. I have a few friends and colleagues who acted similarly with other sites.
I deleted my subscription and account with 23andme. I have a few friends and colleagues who acted similarly with other sites.
Earlier quoted context omitted.
A container is a process with some extra isolation (namespaces), they certainly can't overrun into each other without an exploit. Why would the costs be outlandish? We offer that and we're fairly cheap. Since the cost is mostly fixed per customer, it should scale linearly. As for scaling, they already have to do that, by pointing different requests at different servers depending on their load, etc.
Assuming for a minute that containers aren't in play, then the isolation model becomes that of a server/vm with the associated overhead of each. To make this easier we'll assume there's only a single service, even though we know this to be untrue. If there are 1M customers that's a minimum of 1M servers. Some customers are obviously larger and would need more. There's also HA. Let's conservatively call it 2.5M server…
Why? There's nothing magical about a container, it's literally just a cgroup of Linux processes. You don't have to use them to get the memory isolation we're talking about - uncontained processes get it too.
That's what we do: one process per client, uncontained, just running on a different system user.
But in any case, sure, use containers, I'm certainly not opposed to them.
I would welcome if this incident shone light on possible Cloudflare alternatives. For example, it should be technically doable for DDoS protection service to only initially verify user is not a bot, and then merely tunnel unchanged SSL traffic directly between server and client. Does anyone do this?
Earlier quoted context omitted.
Sure, that's a valid question to ask. But imagine you have 1,000,000 customers. Now you have to calculate and manage scaling groups for 1,000,000 customers * number of services. The resourcing costs alone would be outlandish, not to mention trying to independently scale each customer. Perhaps container systems would make this easier, but do they have better memory isolation? Is it possible for a container process to…
Linux namespaces/containers create a memory page table completely separate from the host's so barring vulnerabilities in the container implementation that allow mapping host physical memory to guest virtual, isolation is strictly enforced by the memory controller in the hardware. Without an exploit, the worst case scenario is leaking shared library read-only sections across containers (since the physical memory might…
Each _process_ has its own memory page table. Containers are built out of processes, so they inherit this attribute.
Namespaces have nothing to do with it.
Earlier quoted context omitted.
Assuming for a minute that containers aren't in play, then the isolation model becomes that of a server/vm with the associated overhead of each. To make this easier we'll assume there's only a single service, even though we know this to be untrue. If there are 1M customers that's a minimum of 1M servers. Some customers are obviously larger and would need more. There's also HA. Let's conservatively call it 2.5M server…
Assuming for a minute that containers aren't in play, then the isolation model becomes that of a server/vm with the associated overhead of each. Why? There's nothing magical about a container, it's literally just a cgroup of Linux processes. You don't have to use them to get the memory isolation we're talking about - uncontained processes get it too. That's what we do: one process per client, uncontained, just runnin…
Perhaps for some tier of paid customer.