Make disclaimer clearer and add methodology section

[Xaekai]

As one of the admins of a site listed in your zip file, I'd like to know how exactly you derived this information, since our site absolutely does not use Cloudflare's reverse proxy.

It does use Cloudflares DNS, but that's not the same thing and didn't expose any users to data leakage.

[tycoonlover1359]

Although I'm not a contributor or otherwise administrator of this repository, I'm going to take a guess saying that your site was included as a precautionary measure. Although your site may be using a different part or service CloudFlare provides, it is better that people change their passwords on this site instead of leaving it the same. This also provides a reason for people to stop using the same password on multiple sites, as this is another way your site's users could have been compromised.

[flaw600]

Not really. It's already been confirmed that Cloudflare DNS was not compromised and the GH admin has said to contact them.

As for @Xaeki, the admin has said that they included all sites that used any Cloudflare service

[basisbit]

@tycoonlover1359 I strongly disagree because in such a case, that service is not affected by #cloudbleed at all.

Sure, you can always tell people to renew their passwords and to not use same password everywhere, but then don't dare to mention any service like cloudflare. Instead you should mention that you screwed up on making certain decisions as website engineer.

[youanden]

@basisbit actually the issue could affect sites not using the technologies if they used the reverse proxy feature by way of memory leaks through other accounts since cloudflare proxies are not dedicated but shared between clients.

[Xaekai]

My point is scraping for every site that just uses Cloudflare's DNS will lead to tens of thousands of false positives. It is irresponsible to list them at all.

[flaw600]

@youanden has that been confirmed or are you simply guessing? Because at face value your explanation seems illogical to me

[flaw600]

Cloudflare to my knowledge has confirmed that customers not using the affected services have not been compromised in their postmortem

[abalabahaha]

The Cloudflare blog post does say this though, which correlates with @youanden's statement:

Because Cloudflare operates a large, shared infrastructure an HTTP request to a Cloudflare web site that was vulnerable to this problem could reveal information about an unrelated other Cloudflare site.

[basisbit]

@abalabahaha @youanden again: as long as you didn't use the cloudflare reverse proxy service, your sites was not affected by this issue. There is no valuable user information that could have been leaked on any website which is for example only using the cloudflare dns service.

[abalabahaha]

@basisbit I was replying to flaw's question to youanden, who specifically stated in his statement that "the issue could affect sites not using the technologies if they used the reverse proxy feature." I agree that if a site wasn't using Cloudflare reverse proxy, it wasn't affected.

[pirate]

@Xaekai I agree that it's slightly misleading to list everything. The issue is that DNS scraping is easy and fast, and will provide an initial list that we can then use to narrow down. The next steps are:

1. narrow down this list by scraping sites to see if they use SSL proxying
2. notify the unaffected sites that they have been removed
3. notify the affected sites that they are still on this list, unless they can prove they were not affected

[Xaekai]

Just because it's easy and fast doesn't mean publishing the results is in any way best practice, professional, on even helpful. The disclaimer that the listed sites may not actually be affected at all should have been much more emphatic.

At the very least, they should have been categorized by method of detection, with an explanation outlining the unreliability of the broader DNS scraping method.

[pirate]

I will add a methodology section, the disclaimer in the README has been boldened to a ###. If you'd like different wording, can you submit a PR?

[youngj]

Also there are some sites that are using the CloudFlare SSL proxy without using CloudFlare DNS -- for example betterment.com is using Amazon Route 53 and is not in sorted_unique_cf.txt . Basically I think you just have to make HTTPS requests and look for the CF-Ray or Server: cloudflare-nginx header. It probably would be useful for someone to write a script to make requests to the domains in sorted_unique_cf.txt and update it to remove the ones that aren't using the SSL proxy.

[mejofi]

I would strongly suggest putting the disclaimer at the top of the README, instead of where it is now.

[tycoonlover1359]

@urc #39

[jrruwe]

You should just remove the connection between cloudflares dns customers and being possibly affected. There is no strong connection between DNS and cloudflare's proxy service. Literally millions of false positives.

[pirate]

@jrruwe I'd argue there is a fairly strong correlation between users of the DNS and proxy services. I've moved the disclaimer to the top.

[mejofi]

@pirate It very much depends. We use Cloudflare DNS for everything, including parked domains that have nothing but SPF, DKIM and DMARC records, and only a handful of zones with A/AAAA and CNAME records actually use the Cloudflare proxy. Out of those, only two are actually affected. The others are static content.

Thanks for moving the disclaimer to the top :)

[pirate]

I've added a Methodology section: https://github.com/pirate/sites-using-cloudflare/blob/master/README.md#methodology

[pirate]

Feel free to comment on this issue and I'll reopen if there are any significant objections. You can also submit a PR if you feel like the methodology wording could be made clearer.