Cloudflare data still in Bing caches
news.ycombinator.com
news.ycombinator.com
The caches other than Google were quick to clear and we've not been able to find active data on them any longer.
...
I agree it's troubling that Google is taking so long.
The leaked information is hard to pinpoint in general, let alone amongst indexes containing billions of pages.
I can understand the frustration - this is a major issue for Cloudflare and it's in everyone's best interests for the cached data to disappear - but it's not easy, and they shouldn't say as such (or incorrectly claim that "The leaked memory has been purged with the help of the search engines" on their blog post).
This is a burden that Cloudflare has placed on the internet community. Each of those indexes - Google, Microsoft Bing, Yahoo, DDG, Baidu, Yandex, ... - have to fix a complicated problem not of their creation. They don't really have a choice either given that the leak contains personally identifiable information - it really is a special sort of hell they've unleashed.
Having previously been part of Common Crawl and knowing many people at Internet Archive, I'm personally slighted. I'm sure it's hellish for the commercial indexes above to properly handle this let alone for non-profits with limited resources.
Flushing everything from a domain isn't a solution - that'd mean deleting history. For Common Crawl or Internet Archive, that's directly against their fundamental purpose.
The very last people in the universe Cloudflare should be criticizing right now are the Google security team.
Why do humans politicize so much? That's one thing I'll never understand, and one of the reasons why I refuse to become a manager.
But what does it really matter?
The length of time this went for was already disastrous. From the Cloudflare blog post, "The earliest date memory could have leaked is 2016-09-22".
As an example of how destructive it might have been beyond leaked information, note that Internet Archive have spent considerable time archiving the election and its aftermath.
donaldjtrump.com is served via Cloudflare.
Chances are it wasn't a domain that was leaking information - though we don't know as there's no publicly accessible list and no way to tell if they had the buffer overrun features active.
If it was however the Internet Archive now have a horrible choice on their hands - wipe data from a domain that will be of historical interest for posterity or try to sanitize the data by removing leaked Cloudflare PII details.
History will already look back at the early digital age with despair - most content will be lost or locked in arcane digital formats. Imagine having to explain that historical context was made worse as humanity deleted it after accidentally mixing PII into random web pages on the internet -_-
The complication comes with the edge cases they'd need to face and @eastdakota's call to "get the crawl team to prioritize the clearing of their caches"[1]. This is also work they now need to do due to Cloudflare's blunder.
For Internet Archive and Common Crawl, these aren't caches, they're historical information. You can't just blow that away - but you also can't serve it if it has PII in it. Either they need to find all the needles and filter/tombstone them - which we'd expect to be very difficult given leaked information is still sitting in Google and Bing's cache now - or wipe/prevent access to the affected domains.
Wiping the donaldjtrump.com would be historically painful but even temporarily blocking access to the domain would be problematic.
Finally, and most importantly, the fact that non-profit projects need to worry about how to exfiltrate such information is ridiculous anyway. Exfiltrating the information is non-trivial as well and may well be destructive with even a minor bug in processing. Having looked at much of the web, it can be hard to tell what's rubbish and what isn't :)
(Fun example: I had an otherwise high quality Java library for HTML processing crash during a MapReduce job as someone used a phone number as a port (i.e. url:port). The internet is weird. The fact it works at all a mystery ;))
Polluter pays.
Why the help was not 100% appreciated...
> Chances are it wasn't a domain that was leaking information - though we don't know as there's no publicly accessible list and no way to tell if they had the buffer overrun features active.
As far as I my understanding goes domains that had the features on were leaking the data of other domains. So it's near impossible to tell who was affected.
And seeing as cloudflare has some of the biggest pipes on the net, it would be easy to saturate a pipe to gather as much data as possible from any sites you can find that are affected.
They seem to care a lot more about marketing than anything else.
(On edit: which also means they have a fucking cheek whining about disclosure timings.)
They mention using the default mod_security rules. I know mod_security can look at the response body, but it is not a default setting.
Tavis Ormandy linking to leaked data to settle some personal groll is a pretty good example how much they really care about data leaks. I guess when you've already leaked all your customers data to intelligence agencies around the world while moving it between data centers it's hard to keep any form of standards.
Want to actually argue your idea with any sort of competition I suggest going outside HN.
Cloudflare has a much stronger incentive to handle the situation in a way that limits the damage to their reputation. As you note, researchers also have an incentive to maximize the benefit to their reputation. But the incentives for P0 are much more closely aligned to the interests of the public here than are the incentives for Cloudflare. The information revealed by the bug is indeed really bad, and there's likely no possible way to tell which of Cloudflare's customers were affected, much less those customers' users. No company wants to acknowledge "yeah, a bunch of our customers' data was compromised, and we have no possible way to tell whether your data was among the data compromised". Their incentives push them to downplay the impact; to accurately describe the potential impact to their customers would probably be disastrous for them as a business. In contrast, downplaying the impact would be contrary to P0's incentive to benefit their own reputation.
Nitpick: you're referring to the web (i.e. HTTP(S)) rather than the internet (UDP, TCP, IPv4, IPv6).
If I place a brick on the cushion on my couch it is correct to say I have placed a brick on my couch.
It just came to me. I'm glad you liked it. :-)
They should be telling them to reset passwords and get users to do similar. And I say this as a generally very happy CloudFlare customer.
A few Bitcoin exchanges have realized the seriousness and have already contacted me and told me to just go ahead and enable 2fa, which I did even on empty accounts. One of which is going so far as to revoke and change their SSL certificates even though there's no reason to believe they were at risk.
Someone correct me if I'm wrong, but:
This isn't just about passwords. Any memory from those proxy servers could have been dumped into these responses, meaning plaintext content of all kinds. The data needs to be purged in addition to telling customers that everything they did in these months has a chance of being out there in plaintext in the hands of random people.
I was just saying passwords because they're something that could have leaked which could be used to actively compromise accounts and result in further attacks now. And probably the only thing most sites can do anything about at this point.
Of course if you were sending private keys, api keys, etc over an SSL connection - those all now need to be treated as exposed.
Some sites may also have special concerns - btc-e for example, a fairly large bitcoin exchange allows users to withdraw to a "btc-e code" which can be deposited by another user of the site. It'd be a serious mess if any of that kind of thing leaked.
In the end Cloudflare should be held responsible. It also puts the whole CDN service business in a bad light.
the publishing part needs to be designed to leverage caching properly tho. however it's much easier to setup cloudflare+custom rules than a cdn push-on-change service
Forget the blame game for a minute: there is personally identifiable information of the search engines users sprayed all over their cache. At this point it doesn't matter who put it there, there's a moral responsibility to clean this up, for the greater good.
A better analogy would be to crash your client’s car into the building of a competitor and then complain if the competitor doesn’t repair that car immediately because it makes you look bad and it is for the greater good for your client to have a working car. This is what happened! Cloudflare took their clients’ cars (their data), crashed them into random buildings all over town (Google, Bing etc.) and now complains that Google and Bing don’t get their act together to repair those cars (remove the private data from the public internet).
If Amazon Prime took your car to do your grocery shopping and then crashed it into Walmart, would you really complain that Walmart can’t send the bill to Amazon Prime for the clean-up?
As a result, tax payers will have to foot the bill for all further mistakes.
It has via robots.txt.
https://www.theguardian.com/technology/2016/feb/11/google-ex...
Crawling the web is something that a lot of people do these days for everything from SEO (Seomoz and every other major SEO tool probably has a crawl) to web data companies (Email Hunter, SimilarWeb, etc.) to national security agencies.
I'd be surprised if there weren't thousands of cached crawls out there that managed to grab some of this data.
But their response here is embarassingly bad. They're blaming Google? And totally downplaying the issue. I really didn't expect this from them. Zero self awareness- or they believe they can just pretend it's not real and it'll go away.
https://www.ovh.ie/cdn/infrastructure/
I know their ddos is pretty good, and it is tiered flat fee, and fairly cheap.
Never used them. Had a quote sitting on the table at one point.
Why does Cloudflare think Google needs to do anything here? It's not illegal. Google shouldn't do anything unless they receive a court order to do so! Why does everyone expect Google to do enforcement here? Google has the right to post this information, it's not illegal to do so, therefore they shouldn't do anything at all about this. Don't you care about freedom of speech? If Google removes this, it creates a slippery slope that will lead to the entire internet being censored.
Google removes info from its index and caches all the time. It's not unreasonable for CloudFlare to expect them to remove this issue. It's just a matter of scale and difficulty.
They actively crawl for piracy sites and isolate them all on one IP, they crawl for child porn sites and straight up remove them.
Why not also remove DDoS sites?
If you find any site has a large number of illegal md5 hashed images going through it; then just remove the site.
Piracy sites can be isolated by checking for keyword clusters or seeing if they're directly serving torrents, or banned hashed content.
We do something similar at work to sanitise image data---by policy no one actually looks at the content, but if you match against previously banned content for DMCA reasons, we drop your data.
DDoS sites though? How can you tell some site individually is part of a network to DDoS another?
Keyword clusters would work just fine for flagging DDoS attack-for-hire content:
https://www.google.com/search?q=ddos+booter
It's extremely obvious what these sites are up to.
Granted I'd never use something as shady sounding as ddos.xyz, but they are plenty of legit companies that do the exact same things.
You'd need a bunch of manual review, and even then it'd become a "we think they're shady" instead of a "they're objectively sharing known illegal content" like it is with illegal pornography or copyright content.
Cloudflare understandably doesn't want to get into the business of being a company that manually reviews the internet (in how many languages?), and boots people who don't meet its tests.
Or they could just remove them when someone points them out to them, which is even harder to explain when you're already working to suppress child pornography and piracy sites using your services.
Because that hurts their business model. They offer commercial protection against DDoS and as such it is not in their business interest.
(Pretty sure you already knew that, just spelling out the obvious)
Your argument is really easy to make. It's also inane and pretty damn insulting to CloudFlare.
But I wonder if it will just mostly go away. Luckily for cloudflare this is a pretty random sampling of people around the country and world. Unless someone has put together a big data set from the caches and decides to leak it or inform the victims, it seems like most people whose accounts do get taken over from this will have no way to trace it back to this bug.
This is a strong argument for simpler systems without multiple third parties as links in the chain.
Do you expect them to close house or ask their clients to leave?
http://securityaffairs.co/wordpress/56650/data-breach/cloudb...
I'm not particularly adept at security. Why would this occur?
For people who do most of their browsing via Tor, it can get annoying to be repeatedly presented with a CAPTCHA.
I kind of understand what CF is doing here: they've screwed up, there's no way for them to clean it up, so all they can do now is deflect attention from the magnitude of their screw up by blaming others for not working fast enough in the hope that their fake paper multibillion dollar valuation doesn't take too big a hit.
Still a dick move though. Maybe next time don't use a language without memory safety to parse untrusted input.
But you'd damn well better fuzz-test the crap out of it before it goes anywhere near a network connection.
Untrusted input is safely parsed by programs written in languages without memory safety all the time. In fact, most language runtimes with memory safety are implemented in languages _without_ memory safety.
What's to criticize here is parsing untrusted input in the same memory space as sensitive information.
(I used to work on Google's PageSpeed Service, and if it had had the same bug I think we would have been in the same situation as CF is now.)
Sure it can. But leaking PII from the thing you're parsing and leaking PII from any other random request isn't the same thing.
I understand the performance implications (and the added effort) of sandboxing the parser, but I'm arguing for it anyway. The mere presence of a man-in-the-middle decrypting HTTPS and pooling cleartext data from many disparate services in a single memory space is already questionable (something for Cloudflare customers - and not Cloudflare itself - to think about) but adding risky features into the mix shouldn't be done without as much isolation as possible.
Let's face it: parsers are about the most likely place for this sort of leakage to happen...
It's definitely possible to fix this (new sandbox per request, cache is fragmented by something outside of sandbox control) but I'm not sure the service would make sense economically.
They use Go more than any other companies, your sentence seems a bit odd.
Aren't they held liable for taking money from those conducting DDOS attacks in the US?
I suspect the random nature of the overflow plaintext spewed out into caches will be difficult to leverage into a statistically significant attack against any particular customer. If CF's bottom line is unlikely to be impacted, why not downplay the issue and refer to it in the past tense?
There may be significant long lasting damage to CF's reputation amongst vulnerability researchers, but that's a tiny subset of the population and statistically insignificant to a company that ~10% of internet traffic flows through.
We are all familiar with "better safe than sorry", but another no-brainer when it comes to security is "remove all uncertainties".
Not only do Cloudflare's CEO and CTO not seem to operate by these golden rules, but they are spreading misinformation to others about the importance of respecting these basic tenants of security. That shows that they place their profit margin over the customers who give them that margin in the first place.
They do not consider routine corporate security, potential legal backlash to their customers, or the safety of their customers' customers to be the most important thing and that is unacceptable for a company that is basically trying to MITM the internet.
Yes, security researchers boycotting CF isn't going to hit their user metrics directly. But what happens when security researchers advise people to use CF because of their poor security/handling of security?
At this point if you don't consider all data that was sent or received by CloudFlare during the "weaponized" window compromised, you're lying to yourself.
If they can't tell, someone may now be sitting on a lot of very juicy data, far beyond what may be left in these caches.
As you say, in the presence of uncertainty it's most prudent to assume that this actually happened.
The reason why I consider them dubious is that anyone simply searching the name of some HTTP headers in Google et all could have stumbled into this. I don't find it at all unlikely to happen in a timespan of 5 months.
So the key question really isn't "how likely was someone to find this", but "how likely is it that Project Zero was the first". I think it's hard to estimate odds, but I'd be surprised if it was even as high as 50%; there's too many teams, individuals, freelancers, state actors, etc. actively engaged in looking for this kind of thing.
The data it reveals isn't guaranteed to be obviously private and exploitable. It can just look like a valid but useless response, or a invalid and corrupted response depending on what you were looking for in the first place.
I mean, how could CloudFlare, or anyone, possibly differentiate this from normal scraping/polling/ manual F5 refresh behavior? This sounds like a PhD thesis.
I guess you are asking CloudFlare to quantify the amount of distinct bytes of unauthorized data sent to any particular user agent? But then, any sophisticated attacker would rotate IPs, UA identifiers, and probably even between vulnerable websites, if they had known about this vulnerability.
I don't think it's reasonably possible to rule this out, even with a massive dedication of investigative resources. Like the other commenter said, it's wisest to assume it happened.
If you have perfect information about what resources were requested when, you can look for a spike in queries for vulnerable resources. Once you see that, you know there was an intentional exploit and can start to look at who drove that spike, what was leaked, etc.
The problem is that we're talking about l huge amounts of data. I'm skeptical that CF has lots of sufficient length and detail to conduct this analysis, but have no real knowledge about their forensic capabilities.
Right now they'll be querying for political blackmail and insider material, then they will turn to Joe Schmoe who only gets his news from the television, where no doubt this will never be discussed. They will effortlessly and listlessly categorize the data largely as an automated process.
If we expect anything less, it's possible we are underestimating our adversaries. Better to overestimate them and feel embarrassed later when you later find out you were just being paranoid.
There is a bit of tension between cloudflare and taviso over the timing of notification, but that is vanishingly insignificant overall.
One causes swapping. The other causes a month of extra work.
If you find some samples with domain names / unique identifiers of domains (e.g. X-Uber-...) you are welcome to contribute to the list: https://github.com/Dorian/doma/blob/master/_data/cloudbleed....
Honest question...
Out of hundreds of passwords I potentially need to reset, I'd like to prioritize.
There is no real way to know what has leaked and from whom. The only ones with real info are CF and it's clear from the amount of sites they've missed in their purge-requests that even them don't really know.
>This list contains all domains that use Cloudflare DNS, not just the Cloudflare proxy (the affected service that leaked data). It's a broad sweeping list that includes everything. Just because a domain is on the list does not mean the site is compromised, and sites may be compromised that do not appear on this list.
Being a DNS customer doesn't mean you're using CF SSL proxy and using the proxy service doesn't mean you're using DNS
- there is a smaller number of sites that used some of the special features of Cloudflare that allowed leakage for some months, according to what Cloudflare said.
- it seems the number of the sites was much bigger for some days, according to what Cloudflare said.
- the data leaked are the data passed through the Cloudflare TLS man-in-the-middle servers -- specifically not only the data from the companies, but the data from the users, and not only the data related to the sites through which the leak happened, but also other sites that just happened to pass through these servers. Again, also the visitor's data, both directions are leaked. From the visitors, their location data, their login data etc. As an example: if you imagine the bank which used Cloudflare TLS, in the caches could be both the reports of the money in the accounts (sent from the bank to the customers) and the login data of the customers (sent by the customers to the bank), even if the bank site hasn't had the "special features" turned on. That's what I was able to see myself in the caches (not for any bank, at least, but the equivalent traffic).
To be clear, the SSL and caches are isolated from the process that handles transformations of web pages and neither of those leaked anything.
All traffic that is "orange clouded" passes through the transformation layer and may have leaked by any of the pages on the sites that had this unique set of features enabled (the cause) and also had broken HTML (the trigger) if they happened to be in the memory immediately after the broken HTML.
Which means that a small number of sites (3,438 domains - cite jgc) were able to leak the first bit of memory for requests located in memory after the page request of a broken page on one of those small number of sites... and this other memory could have been any other page that is proxied by Cloudflare.
Is it huge? Absolutely, because the leaked pages could have contained anything, especially in the headers which will have been included.
Is it a lot of pages? The scale of Cloudflare means no matter how small the fraction affected it adds up, so yes. The sum of pages that will have leaked data is horrifying because even a single page is a page too many to leak.
Are you a customer, are you paranoid and want to know what to do? OK, then change your origin server IP addresses, and expire your user sessions/cookies. Beyond this, you will need to look at your own web application to determine whether in the first bit of a response from your origin servers you include sensitive data, and from that what you feel is an appropriate action.
The only thing I'm doing to my sites is working through an expiry of user sessions. Even then, I think the chances that I was affected remain vanishingly small but expiring sessions is the responsible thing for me to do.
Note: I work at Cloudflare but wasn't involved in this security incident beyond helping to find data in caches. Additionally I run 300+ websites that are all behind Cloudflare web proxy so I understand that perspective extremely well.
It's some kilobytes of browser requests or server responses that are leaked in the samples I have seen, if I remember correctly. Much more than "the first bit."
Just to be clear.
To be very precise, I think jgc mentioned that up to 4KB from the bounds of the initial request could have been leaked, where a good section of that was the internal server-to-server communication certs, the raw headers as visible during the internal processing of the request, and then part of the response body that follows... this may have been encrypted or compressed and could appear as garbage.
The focus for site owners on Cloudflare should be on "What do I put in headers that may be sensitive?" or "What URLs do I regard as being secret/unadvertised?".
Typically that will be session cookies and access_tokens. Hence my advice, expire and roll all sessions.
Headers include the Cloudflare internal headers, and so includes origin IP addresses too, so if those are secret for you (i.e. you have previously been the target of a DoS and are using Cloudflare to hide those IPs) then you'll want to change your origin IP addresses too. Though if you have been the target of a DoS then you probably should use iptables to only allow web traffic from Cloudflare IP addresses.
Either we can search for obvious strings like X-Uber-* and try to scrub them one by one, or we can just nuke the caches for all the domains that turned on the problematic features (Scrape Shield, etc.) anytime between last September and last weekend. Cloudflare should supply the full list to all the known search engines including the Internet Archive. Anything less than that is gross negligence.
If Cloudflare doesn't want to (or cannot) supply the full list of affected domains, an alternative would be to nuke the caches for all the domains that resolved to a Cloudflare IP [1] anytime between last September and last weekend. I'm pretty sure that Google and Bing can compile this information from their records. They might also be able to tell, even without Cloudflare's cooperation, which of those websites used the problematic features.
This CloudFlare breach seems to have put a lot of people in a tough spot, but it feels like it's put archivists in an impossible position.
It might not be unreasonable to say that this privilege comes with a certain responsibility to ensure that those copies do not cause excessive harm to others.
So although Cloudflare is the one that fucked up, Google et al. also have a responsibility to do whatever they can to protect the public. They should do what they can, with or without Cloudflare's cooperation.
When there's an oil spill, we don't wait for the oil company to come and clean up their own mess. Others clean it up a.s.a.p. and (ideally) then make the oil company pay the fines and damages. CloudBleed is a virtual oil spill. They literally sprayed other people's private data all over the internet.
First, we're talking about raw memory pages, not merely malformed HTML. Those memory pages might contain valid HTML, but most of the sensitive information is in the headers, not HTML markup. It won't be very difficult to write a script to identify documents where random headers and POST data have been inserted where they don't belong, or where the markup is so obviously invalid (even compared to similar documents from the same site) that there is a high probability of contamination. Having a full list of contaminated domains would obviously help a lot, because we'll only have to deal with thousands of domains instead of millions.
Second, contaminated documents by definition contain information that is NOT what the publisher intended to be crawled, indexed, or archived. So there should be less resistance to removing them.
Finally, most of the contaminated domains used features such as Scrape Shield that were intended to deter archival. It's as if the domain had a robots.txt that said "User-agent:* Disallow:/". I'm not sure whether it's even possible for the Internet Archive to archive such domains. If they can, maybe they've been doing it against the publisher's wishes. If they can't, well, there's no problem to begin with.
So I would completely disagree with your speculation about what's easy or hard. (Note that I've worked at a search engine and an archive.)
No, IIUC it's MUCH worse than that : a single nginx process would serve many different domains, and you would only need one of them with the problematic features turned on to trigger the bug, and potentially leak data from all other domains served by that same process (whether those other domains had the feature enabled or not)
I'm not familiar enough with CF's infrastructure to make an educated guess about the way they shard domains across their nginx fleet (assuming this is what they do), but in order to be able to produce a list of all "tainted" domains that were being served together on the same nginx process, at any point in time since September 2016, well their nginx config generation process had better be perfectly deterministic (and any changes thoroughly logged over time). Also, the bigger the shards, the more neighboring domains are affected by a single "poisoned" one, and the more widespread the problem is.
My guess is that if they had had a way to reliably piece together that information, they would have released a list by now.
Or they've got that list - and it's so vast and scary that legal and/or the board refuse to even acknowledge its existence…
AWS? Cheap? Really?
If this is how 2017 is pacing, we've got a long year ahead. This is an insanely interesting time to be alive, let alone at the forefront of the INTERNET.
Fellow Hackers, I wish you all the best 2017 possible.
>Google, Microsoft Bing, Yahoo, DDG, Baidu, Yandex, and more. The caches other than Google were quick to clear and we've not been able to find active data on them any longer. We have a team that is continuing to search these and other potential caches online and our support team has been briefed to forward any reports immediately to this team.
>I agree it's troubling that Google is taking so long. We were working with them to coordinate disclosure after their caches were cleared. While I am thankful to the Project Zero team for their informing us of the issue quickly, I'm troubled that they went ahead with disclosure before Google crawl team could complete the refresh of their own cache. We have continued to escalate this within Google to get the crawl team to prioritize the clearing of their caches as that is the highest priority remaining remediation step. reply
taviso 6 hours ago [-] Tavis Ormandy
>Matthew, with all due respect, you don't know what you're talking about.
>[Bunch of Bing Links]
>Not as simple as you thought?
My personal favorites are:
What happens for sites using Full SSL (a certificate between cloudflare and the user and a certificate between cloudflare and the server), could any information from ssl pages have been leaked?
If CF decrypts information you send to it before encrypting it to your users, that's a step where plaintext might have been present in their servers' memory.
(Please correct me if I'm wrong.)
In this case, certain CF features when enabled would transform the HTML that was sent to users, and sometimes it would include random bits of the server's memory in the output. These bits of memory could include anything like private data from other requests and responses being handled by the server.
This is very similar to the openssl heartbleed issue which also exposed random bits of the server's memory under certain conditions.
Is there some sort of information extraction feature service or something they offer? I don't get it.
If I were google I would hit back hard. They prob won't just stop, but I would not bother trying to even clean up the data unless under legal pressure. It out there, it's too late.
From their blog: https://blog.cloudflare.com/incident-report-on-memory-leak-c...
Is it possible to find if anything leaked from my site behind Cloudflare is in the caches?
It lets you run domains quickly without downloading and grepping.
With regards to the fact that it's part of another thread, I don't think that matters too much. If it were an update present as a separate document it would pass muster. There've been several open letters, and responses to such, and further responses again, etc that have been posted to HN. Furthermore there's no guarantee that someone reading the original thread will see this exchange; I read the thread after the exchange happened and missed it.
This is significant enough to be posted as its own item, that it's part of another, ongoing thread shouldn't take precedence over this significance.
The thing itself seems somewhat newsworthy but personally, I'd rather hear the CF people defend the TLS-MITM-as-service idea itself and get yelled at for that. The fact they're being weaselly and insufficiently contrite seems secondary.
23. Announcing the first SHA-1 collision (googleblog.com)
2882 points by pfg 1 day ago | flag | hide | 488 comments
37. Cloudflare Reverse Proxies Are Dumping Uninitialized Memory (chromium.org)
3168 points by tptacek 1 day ago | flag | hide | 979 comments
Not exactly breaking news. At some point, maybe people will realise that CF is actively making internet worse and less secure, and that it should be treated as nothing more than a wart to be removed.
Edit: I wasn't very clear. GP is wrong saying MITM is "wrong" for its own sake. I think Cloudflare is harmful for other reasons though.
I'm not sure what this has to do with all CDNs being MITM operators when caching secure content.
I edited my comment.
If you're saying not to use any CDNs then that's not very reasonable considering the service that CDNs provide.
Everything on the internet is a product of thousands of vendors, hardware equipment and software components working together. There are millions of factors that can and may be compromised so the only realistic approach is risk management.
It's far better to rely on a well funded, staffed and capable vendor rather than building your own version. This is solid advice for everything outside of the expertise of your business so I'm not sure why a CDN is anything different. Assess the risk and do what works for you.