
List of Sites Affected by Cloudflare's HTTPS Traffic Leak - emilong
https://github.com/pirate/sites-using-cloudflare/blob/master/README.md
======
r1ch
Just got this classy spam from dyn.com. Wonder if they're going through this
list emailing every domain contact.

> As you may be aware, Cloudflare incurred a security breach where user data
> from 3,400 websites was leaked and cached by search engines as a result of a
> bug. Sites affected included major ones like Uber, Fitbit, and OKCupid.

> Cloudflare has admitted that the breach occurred, but Ormandy and other
> security researchers believe the company is underplaying the severity of the
> incident …

> This incident sheds light and underlines the vulnerability of Cloudflare's
> network. Right now you could be at continued risk for security and network
> problems. Here at Dyn, we would like to extend a helpful hand in the event
> that your network infrastructure has been impacted by today's security
> breach or if the latest news has you rethinking your relationship with
> Cloudflare.

> Let me know if you would be interested in having a conversation about Dyn's
> DNS & Internet performance solutions.

> I look forward to hearing back from you.

~~~
IgorPartola
It's clever but feels at least a 3/10 shitty. Dyn is an old company and back
in the day they provided free subdomains while nobody else did. I haven't used
them recently because their pricing seems so high. How do others feel about
them?

~~~
r1ch
I still have a lifetime standard DNS subscription with them from back in the
day when they were dyndns.org and you could physically mail them cash. The DNS
hosting has been very solid (except for the day Mirai took them offline) but
the standard query limits are way too low for any moderately trafficked
website. All the managed DNS providers I looked at seem to have very
restrictive query limits without a "enterprise - contact us" plan, one of the
reasons why I decided to just do DNS-only on Cloudflare.

~~~
ticoombs
Why not he.net?

~~~
r1ch
I use he.net DNS quite a lot for personal projects. I've had a few instances
where DNS was not resolving that make me a bit cautious to move larger sites
onto their service.

------
actuator
I wrote this(1) script to check for any affected sites from local Chrome
history. It checks for the header `cf-ray` in the response headers from the
domain. It is not an exhaustive list but I was able to find few important ones
like my bank site.

1:
[https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d...](https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d586f064)

~~~
poorman
I wish 1Password had a feature where you could put in a list of domains like
this or a "Auto Change Possibly Compromised Passwords" feature.

~~~
erichurkman
Isn't this what Watchtower is supposed to be for? I have no idea if AgileBits
is going to add this list to Watchtower, though.

~~~
AGKyle
Disclaimer: I work for AgileBits, makers of 1Password

I am helping comb through a list of sites to see which of those has suggested
password updates.

I think we've had very few sites suggest updating the password though. Have
you all seen any sites explicitly state users should update? If so I'd love a
list so we can get them in Watchtower.

Kyle

~~~
data4science
I would subscribe to Watchtower, or, heck, probably even 1Password Famlies, if
AgileBits took a more aggressive/proactive approach to password updates: 1\.
Prompt batch password resets for services whose vulnerabilities have been
exposed _before_ those exposed admit their breach to consumers (e.g. _All_
services compromised by the Cloudflare dump - usually consumers are the last
to know). 2\. Preformed _all_ password resets in a secure AgileBits browser
(assuming the browser built-in to 1Password on iOS is secure). 3\. Had an
optional prompt to prevent unintentionally syncing/backing-up 1Password data,
and accessing said secure browser without first confirming VPN status with the
operating system (maybe even prompt user to connect to VPN before unlocking if
VPN connection isn't established)

Alternatively, I'd subscribe for integration of a 1Password browser extension
for a reputable (regularly high, multiplatform AV-Test/NSS performance)
internet security service's browser, and Watchtower was as sensitive as
mentioned above and integrated with said internet security service.

This is coming from a longtime 1Password Pro user (3-6 yrs) who recently got
his family on the 1Password bandwagon.

~~~
drakenot
Yep, I totally agree. Before I read this thread, I actually tweeted to
1Password to ask if they would be willing to produce some way for me to
quickly cross reference the Cloudbleed sites against my 1Password vault.

I think Watchtower alerts should be based on _any_ publicly known breach, not
based on what the companies themselves say.

At this point, I consider any account using an affected Cloudflare service as
potentially compromised.

This is a missed opportunity for 1Password to say that not _only_ is your
vault safe, but we will _also_ help protect you from any potentially sites
that had their data exposed.

------
crottypeter
Today I learned that uber does not have a change password option once you are
logged in. You have to log out and pretend you forgot the password. Bad UX if
you don't know.

~~~
spb
Holy crap, really? I've been drawing up [profiles for the user account systems
of a bunch of websites for the past few years][1], and I think I've only seen
that _once_ before (on a Washington State website, no less).

[1]:
[https://github.com/opws/domainprofiles](https://github.com/opws/domainprofiles)

~~~
ams6110
Fairly common pattern on non-tech-oriented sites, in my experience.

------
ig1
Worth noting this statement by Cloudflare CTO:

"I am not changing any of my passwords. I think the probability that somebody
saw something is so low it's not something I am concerned about."

[http://www.bbc.co.uk/news/technology-39077611](http://www.bbc.co.uk/news/technology-39077611)

~~~
mbesto
*Article says COO, but Twitter says CTO. Strange.

And he's fairly active on these forums. That seems like such an odd thing to
say given how important security is/should be at CF...curious if jgrahamc
would further clarify his position here.

~~~
fencepost
Agreed on the importance of security, but if his credentials from outside
their network are able to be used in any significant way to impact their
services or systems then they're doing something _tragically_ wrong. For that
matter if his credentials can be used _anywhere_ to impact their services it's
a failure.

------
nikisweeting
Aww man I submitted my list hours ago but I guess it never made it past the
New page. [https://github.com/pirate/sites-using-
cloudflare](https://github.com/pirate/sites-using-cloudflare)

Original post:
[https://news.ycombinator.com/item?id=13720199](https://news.ycombinator.com/item?id=13720199)

~~~
dikaiosune
Hey! Super useful, thanks.

Quick question: news.ycombinator.com (as an example) is listed in the README
as a potentially affected site, but I don't see it in the raw dump that I've
downloaded. Am I crazy?

~~~
edaemon
I suspect the raw dump is a list of sites that use the CloudFlare DNS servers,
but HN uses a CNAME setup on their own authoritative DNS servers so it
wouldn't appear in that list.

------
koolba
That's a wide impact. While any hijacked account is bad, some of these are
_really_ bad.

For example, [https://coinbase.com](https://coinbase.com) is on that list! If
they haven't immediately invalidated every single HTTP session after hearing
this news this is going to be bad. Ditto for forcing password resets.

A hijacked account that can irrevocably send digital currency to an anonymous
bad guy's account would be target number one for using data like this.

~~~
pyre
I also noticed the domain waveapps.com, which is for Wave Accounting.

~~~
rmaurin
Cloudfare has advised that Wave data has not been affected/leaked. We've got
engineering and security teams investigating, and we'll keep on it until we're
ultra confident in the conclusion. Nonetheless, good practice for everyone to
rotate all passwords today, for any services. Good security hygiene any time,
and especially now.

~~~
petters
How can they know that?

A broken web page could have been queried many, many times the last weeks and
couldn't one of the responses contain Wave data?

~~~
rmaurin
Not 100% sure what their methodology is yet, and we're taking a cautious
approach. At minimum, in the data that they've found in the wild, no Wave data
was among it.

------
Cyphase
You missed the "possibly" in the header.

And the disclaimer right at the top:

 _This list contains all domains that use cloudflare DNS, not just the
cloudflare SSL 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._

~~~
eli
Affected sites leaked data from random other CF customers. So any site using
CF regardless of settings could have leaked private data out there.

~~~
r1ch
Sites using Cloudflare in DNS only mode won't have sent any requests that
could be leaked.

~~~
wallacoloo
Indeed, and it's pretty annoying having my site in that list despite _not_
using CloudFlare's reverse proxy service. If my website handled user logins or
sensitive data no doubt I'd have customers contacting me or shying away from
my site now. This list needs more vetting.

~~~
gkop
Do you have a concrete suggestion for the list maintainer to better vet the
list?

Can you prove that your site did not use the reverse proxy service at any
point while the vulnerability was live?

~~~
wallacoloo
> Can you prove that your site did not use the reverse proxy service at any
> point while the vulnerability was live?

This is a scenario where it's _impossible_ to prove innocence. Even if
somebody provided you with the logs of their DNS server to show that the
website never pointed to CloudFlare, I doubt these logs were stored in a way
that their authenticity could be proved. In any case, the onus of proof should
almost always be on the accuser, not the accused.

Since you pressure me for a suggestion: my suggestion would have been to only
list websites that were using the reverse proxy service (as opposed to DNS) at
the time the data was captured. This can be done by inspecting the http
response headers, or maybe even just checking the DNS records against known
CloudFlare servers (as opposed to checking the DNS _provider_ ).

But since you point out the transience of this, this method, as well as the
method used to gather the list as-is are fundamentally flawed. I think a
better way would be to locate DNS dumps throughout the vulnerability period &
apply the above method to those.

~~~
gkop
Thanks for answering!

Your last idea is a good idea but more work for the list editor. I'm not sure
the motivations of the list editor, but if he or she is just an impartial
volunteer (important assumption), it seems like it's really Cloudflare's
responsibility to deliver a comprehensive report of affected sites, so that we
don't have to guess?

------
pulls
For what it's worth, as part of work on the effects of DNS on Tor's anonymity
[1] we visited Alexa top-1M in April 2016, recording all DNS requests made by
Tor Browser for each site. We found that 6.4% of primary domains (the sites on
the Alexa list) were behind a Cloudflare IPv4-address. However, for 25.8% of
all sites, at least one domain on the site used Cloudflare. That's a big chunk
of the Internet.

[1]: [https://nymity.ch/tor-dns/](https://nymity.ch/tor-dns/)

------
cloudvrfy
I wrote a simple website[1] to show if user have visited the websites included
in the list automatically without browser plug-ins. It uses :visited CSS
pseudo-class to highlight the site user have visited before. It is not 100%
accurate, but it can be a fun way to quickly show people that they may visit
sites on the list.

[1][https://cloudbleed.github.io/](https://cloudbleed.github.io/)

~~~
salemh
I want to share this with my more non-techy persons, but, on Chrome, turning
of uOrigin, their are no names of companies listed. I can hover over every
block for the name, but.. is this an error, or intentional to just have a
large heart-block with no labels?

~~~
cloudvrfy
Could you suggest how the names of companies should be shown so we can improve
the website? Appreciate your reply :)

~~~
salemh
Just a right-side text that highlights once you mouse-over would be great. It
may be too much to display all of names, but having it populate gives some
idea of where you need to go.

Perhaps just every "red"/affected site could be populated on the right side :)

Appreciate the layout outside of naming labels however, nice work.

------
jitbit
Webmasters and App-devs running on CloudFlare. You (at least) have to "force-
logout" your users that have a "remember me" cookie set.

At least change the cookie name so the token stops working. For example, in
ASP.NET - change the "forms-auth" name in the web.config file

~~~
cortesoft
If you do that, then an attacker could just use the same token with a
different cookie name and access someones account. You NEED to invalidate the
token.

------
Splines
If I have an account on an affected site, but did not interact with the site
(via my browser or through some other site with an API call) during the time
period when the vuln was live, am I still at risk?

~~~
tkeith
It seems very unlikely that you would be at risk, but there's some remote
possibility that your past request data was in memory for some reason

------
edaemon
This list doesn't appear to include sites that use a CNAME setup with
CloudFlare -- i.e. sites on the Business or Enterprise plans that retain their
authoritative DNS and use CNAMEs to point domains to a CloudFlare proxy.

There probably aren't many but with something this serious it could be
important. I'm not sure how one would go about finding the sites that use the
CNAME option. If it helps, they use a pattern like:

    
    
      www.example.com --> www.example.com.cdn.cloudflare.net
    

Hacker News is one such site, but it's listed in the "notable" section (it's
not in the raw dump).

------
JaggedJax
In an email from Cloudflare sent out this morning they said:

> In our review of these third party caches, we discovered data that had been
> exposed from approximately 150 of Cloudflare's customers across our Free,
> Pro, Business, and Enterprise plans. We have reached out to these customers
> directly to provide them with a copy of the data that was exposed, help them
> understand its impact, and help them mitigate that impact.

Does this jive at all with the Google or Cloudflare disclosures? They are
claiming that across all caches they only found and wiped data from ~150
domains, can that be true?

~~~
mistercow
Every single thing Cloudflare has said about impact has sounded very
suspiciously optimistic to me. For example, they claim that they would know if
an attacker had been intentionally exploiting this bug, but I've seen no
details to justify their confidence.

So no, I don't think we can assume that the scope was as limited as they're
making out.

Edit: As my coworker points out, as of 2013, they only kept 4 hours of access
logs (source: [https://blog.cloudflare.com/what-cloudflare-
logs/](https://blog.cloudflare.com/what-cloudflare-logs/)). So basically their
existing attack detection infrastructure (built without knowledge of this bug)
may not have found anything suspicious, but it appears that that's the extent
of what they can say about the last few months. They can claim that they found
no evidence within the last week (one hopes that they stopped discarding logs
when they found out about the attack), but if they want to convince us that
they know this wasn't being exploited as late as two weeks ago, they need to
provide specific evidence.

------
jschpp
That list isn't that useful... First of all, there is a LOT of pages hosted by
CloudFlare @taviso acknowledged that in the original bug report.
([https://bugs.chromium.org/p/project-
zero/issues/detail?id=11...](https://bugs.chromium.org/p/project-
zero/issues/detail?id=1139#c5)) Furthermore, you can't say which sites were
hit by this bug and simply listing all CloudFlare sites is more or less
fearmongering. If you are a verified victim of this bug CloudFlare will
contact you. Lastly, if you want to be sure to mitigate effects of the attack
just do it... If you want to be absolutely sure that your session keys etc
will remain uncompromised simply repeal all active session cookies.

~~~
safeaim
While Cloudflare might contact their customers, it's no guarantee that the
customers will actually notify their users, so I think this is a good way to
find out which sites I might have to change my passwords and API keys on.

~~~
tyingq
The email Cloudflare is sending out to customers where Cloudflare didn't find
any cached info isn't particularly alarming:
[http://pastebin.com/pUnKJE3J](http://pastebin.com/pUnKJE3J)

I wouldn't be surprised if people receiving this took no action.

~~~
yeukhon
Well, in the Google Zero Project issue ticket, the engineer said he felt
Cloudflare tried to downplay the severity and it took them extra days and a
lot of demanding from Google Zero Project team to finally get a draft (which
from a legal and a company reputation PoV that makes sense; you need a lot of
eyes on the draft before going out to the public).

I think not every "leak" is sensitive, but there are definitely instances Cf
and Google both found very sensitive information.

------
vmarsy
Something I have a hard time understanding, is how Cloudfare's cache generator
page had access to sensitive information ?

Were the 2 things running on the same process? If they were not, there's no
way that the buffer overrun could read an other process memory, right? it
would have failed with a segfault type of error.

If so, shouldn't Cloudfare consider running the sensitive stuff on a different
process, so that no matter how buggy their caching engine is, it would never
inadvertently read sensitive information?

~~~
cjslep
SSL connections were terminating at the proxy, so the proxy used plain HTTP to
the web service backends.

~~~
jpetersonmn
Are you sure about this? Just because they terminate ssl on the proxy doesn't
mean the traffic between the proxy and the web service backends was plain
HTTP. That's certainly not how we do things.

------
nodesocket
This is ridiculous and somewhat irresponsible. This is just a list of domains
using CloudFlare. The leak was only active under a set of very specific cases
(email obfuscation, server-side excludes and automatic https rewrites).

I question Pirates ([https://github.com/pirate](https://github.com/pirate))
motives for even doing this? Karma? Reputation?

~~~
kijin
Only a few hundred sites were leaking, sure, but the leaked info could have
come from any domain that was being proxied by the same edge server. So we
would do better to assume that any domain that uses Cloudflare could have had
their passwords and other sensitive info exposed via leaky neighbors.

------
jandy
I'm confused by the "not affected" remarks. I thought the issue was any site
which passes data through cloudflare could be leaked by requests to a
different site, due to their data being in memory. Have I misunderstood?

~~~
noahm
The update from 1password indicated that there was application layer
encryption happening in addition to the TLS encryption, so a breach of the TLS
protection did not expose any sensitive data. Presumably other sites are in
similar situations. But don't take my word for it, go change all your
passwords.

~~~
orthecreedence
> Presumably other sites are in similar situations.

Not to my understanding. 1password uses client-side encryption, using keys
generated from your master password. This means that any data transmitted over
the wire is already encrypted, whether over SSL or not.

Most other sites do _not_ do this, at all, in any way. If you use a website
that use'd CloudFlare's SSL termination, change your passwords, cancel your
credit card (if you sent it to that site in the past few months, eg
Uber/Lyft).

> go change all your passwords.

Yes, correct =].

~~~
markonen
If you'd seriously cancel your credit cards over this, I'd love to hear how
you model that threat relative to all the other risks inherent in using a
credit card anywhere (not just online).

------
arca_vorago
Apparently root case was:

/* generated code */ if ( ++p == pe ) goto _test_eof;

"The root cause of the bug was that reaching the end of a buffer was checked
using the equality operator and a pointer was able to step past the end of the
buffer. This is known as a buffer overrun. Had the check been done using >=
instead of == jumping over the buffer end would have been caught."

Detailed timeline:

"2017-02-18 0011 Tweet from Tavis Ormandy asking for Cloudflare contact
information

2017-02-18 0032 Cloudflare receives details of bug from Google

2017-02-18 0040 Cross functional team assembles in San Francisco

2017-02-18 0119 Email Obfuscation disabled worldwide

2017-02-18 0122 London team joins

2017-02-18 0424 Automatic HTTPS Rewrites disabled worldwide

2017-02-18 0722 Patch implementing kill switch for cf-html parser deployed
worldwide

2017-02-20 2159 SAFE_CHAR fix deployed globally

2017-02-21 1803 Automatic HTTPS Rewrites, Server-Side Excludes and Email
Obfuscation re-enabled worldwide"

Seems like a pretty good response by cloudflare to me.

~~~
kevinchen
It's a good postmortem (describes WHAT happened), but it doesn't really
communicate the impact to Cloudflare customers or their end users (describe
WHY people should care).

------
dikaiosune
I've been tinkering with a Python notebook for a few minutes to try to quickly
assess how much of my LastPass vault is affected:

[https://gist.github.com/dikaiosune/0ca7829884b3b3f790418f0f1...](https://gist.github.com/dikaiosune/0ca7829884b3b3f790418f0f108fd38f)

Improvements welcome.

One interesting thing: the raw dump that's linked from the list's README
doesn't seem to include a couple of notable domains from the README itself,
like news.ycombinator.com or reddit.com. I may be mangling the dump or
incorrectly downloading it in some way.

EDIT: disclaimer, be responsible, audit how the dump is generated, etc etc etc

------
AdmiralAsshat
Authy is on the list. It would be _really_ nice if they confirmed whether they
are vulnerable or not, considering they hold all of my 2FA tokens. Otherwise
I'll have to re-key the database.

~~~
infinite8s
Wouldn't you rather just do that as a precaution? Then you won't be constantly
worried that they might have had their data leaked.

------
RidleyL
I wrote a python script to help check your LastPass database for any
potentially affected sites.

[https://github.com/RidleyLarsen/cloudbleed_check_lastpass](https://github.com/RidleyLarsen/cloudbleed_check_lastpass)

------
danjoc
Is there a "standard" in the works for changing a password? Stuff like this is
happening rather too frequently for my taste. I need a tool I can use to
update all my passwords everywhere automatically and store the new ones in my
password manager.

~~~
jbkly7
LastPass has auto-password change: [https://blog.lastpass.com/2015/05/auto-
password-change-now-a...](https://blog.lastpass.com/2015/05/auto-password-
change-now-available-in-the-lastpass-security-challenge.html/)

~~~
soundoflight
Dashlane has that feature too.

------
grogenaut
I ginned up this little tool tonight to help people out instead of grepping.

[https://bleed.cloud/index.html](https://bleed.cloud/index.html)

Sorry for the index.html, trying to figure out how to get index file to work
on cloudfront.

You can also run the python script on the website anonymously on your computer
to dig sites out of your email, which is a good indicator that you have an
account with them.

------
pmontra
I have hundreds of passwords in my password manager. That's going to take a
week, considering I also have to work.

~~~
chrisbolt
Is your password manager 1Password?

[https://blog.agilebits.com/2017/02/23/three-layers-of-
encryp...](https://blog.agilebits.com/2017/02/23/three-layers-of-encryption-
keeps-you-safe-when-ssltls-fails/)

~~~
pmontra
No, it's keepassx on my laptop. I don't trust my passwords to somebody else.

~~~
ComputerGuru
So why do you have to change them all?

~~~
pmontra
My cleartext passwords could have been dumped into the responses of some other
site together with my user names. That's the gist of this incident.

~~~
therealmarv
I still don't understand why you have to change every password (are not they
supposed to be all different in a password manager?). Of course if you are
super extra mega careful then change them all...

~~~
paulddraper
pmontra doesn't have to change every password, just every password used by a
website using Cloudflare (thus the purpose of the list of affected sites).

------
Wrhector
This list seems to be missing any sites that are using custom nameservers,
which would be common on top sites using the enterprise plans. A better way to
detect if the proxy is being used would be to resolve the IP and see if it
lies in Cloudflare's subnets.

------
kiallmacinnes
And, I've found several of my domains on this list.. Some of which don't host
web content etc and only use cloudflare for DNS. The list is currently ~4.3mil
entries, which honestly feels like a rather low figure. I have no data to back
up my gut feeling though ;)

Anyway, I'm OK with them being on this list, as I believe understanding the
scope of the problem is important to figuring out how we prevent these kinda
problems in the future.. (For example, answering this question requires
understanding who uses CloudFlare: Why are so many sites concentrated on a
single infrastructure?)

------
janwillemb
Thanks for posting and curating this list.

------
luckystartup
Oh crap. I've entered my banking password into Transferwise quite a few times.

Welp, time to change all my passwords.

~~~
pc86
> _Welp, time to stop using the same password for multiple services._

> _Welp, time to start using a password manager._

FTFY

~~~
doubleunplussed
OP isn't saying they used the same password for transferwise as for their
bank. Transferwise allows you to log into your internet banking and authorize
a transaction through their site. You actually give them your internet banking
password, regardless of how you log into their site.

Which is pretty strange in itself, to trust a 3rd party with your internet
banking password, but that's how it works.

~~~
philsnow
This is the main reason I've never used Mint.

------
pbhjpbhj
Do browsers still leak history info (eg
[http://zyan.scripts.mit.edu/sniffly/](http://zyan.scripts.mit.edu/sniffly/))
is it possible to have a page show visitors if they are likely to be affected?

------
iKenshu
What if I sign in with facebook or other? Should I change muy password con
facebook or what?

~~~
Crosseye_Jack
TL;DR? You should be ok...

Long Version.

That (most likely) would of used oauth. So instead of sending your FB password
to the site to log you into FB with. You give your FB password (if your not
signed in) to FB and then facebook give the site using "sign in with Facebook"
a token they can use with facebook to get account info / do actions on your FB
account.

Now depending on which "sign in with" system you used then often the code
handed back to the site (via a callback URL handled by the client) is a single
use code. So once the site using "sign in with" has used the code with FB they
get another set of tokens they will use with Facebook directly.

After the initial "sign in with" process the Facebook tokens are most likely
never handed to clients (because they often need to be mixed with a site
secret during requests to the likes of Facebook).

So you _should_ be ok if you used a decent "sign in with" system like
facebooks as the only thing that would of been handed back to the client and
then sent from the client to the site is that single use code. The
communication with the site and facebook would of used an API endpoint.

Now... If you used another sites (not facebook) "sign in with" system and
their API is also behind Cloudflare it could well be that some API keys could
be in a cache somewhere. If those requests were signed with secrets you should
be fine because without the sites secrets to lets say create a hmac signature
for the request then while there might be some personally identifiable
information in caches somewhere the signatures should of already expired
meaning that they can't be used in say a replay attack and the data cached
can't be used to create fresh requests.

BUT this all depends on everyone doing things right, which may not be the
case. But either way, oauth tokens are often not revoked when you change your
password. I.e. you might change your FB password and then still be able to
auto login on somesmallsite.org because the tokens shared between FB and
somesmallsite.whatever haven't changed.

~~~
iKenshu
Thanks for this answer, its perfect!

------
paradite
Couldn't find a practical description of who is affected anywhere. Is it just
the customers who have Cloudflare HTTPS proxy service being affected, or
anyone using Cloudflare DNS is affected?

~~~
dsl
Anyone who passes HTTP or HTTPS traffic via CloudFlare might have had that
data leaked into other users sessions.

------
base698
Has Cloudflare fixed the issues? Should I update passwords now or wait?

~~~
spiffytech
Yes, they've fixed the issue, so it's safe to change your passwords now. But
expect some websites to prompt you to change your passwords again once they
disclose the breach.

------
arikrak
It would be more useful if there was a way to see sites that actually were
using the Cloudflare features that caused this bug. A large number of sites
use Cloudflare, but few should have been affected by this bug:

> When the parser was used in combination with three Cloudflare
> features—e-mail obfuscation, server-side excludes, and Automatic HTTPS
> Rewrites—it caused Cloudflare edge servers to leak pseudo random memory
> contents into certain HTTP responses.
> [https://arstechnica.com/security/2017/02/serious-
> cloudflare-...](https://arstechnica.com/security/2017/02/serious-cloudflare-
> bug-exposed-a-potpourri-of-secret-customer-data/)

~~~
cknight
As has been mentioned elsewhere on HN, those 3 features were capable of
triggering the bug. Once triggered, potentially any Cloudflare-enabled site
could have been affected.

------
vasundhar
Unfortunately this seem to include news.ycombinator.com

~~~
shakna
> This list contains all domains that use cloudflare DNS, not just the
> cloudflare SSL 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.

In this case, HN , IIRC, does not use the proxy.

Checking the certs, CloudFlare reissue using DigiCert, I think, whereas HN is
using a Comodo cert.

~~~
dsl
You can upload your own cert to CloudFlare.

Hacker News does hit the CF proxy and was affected.

    
    
      $ host news.ycombinator.com
      news.ycombinator.com is an alias for news.ycombinator.com.cdn.cloudflare.net.
      news.ycombinator.com.cdn.cloudflare.net has address 104.20.44.44
      news.ycombinator.com.cdn.cloudflare.net has address 104.20.43.44

------
em0ney
The list of websites once again reminds me of what avenue Q immortalised in
song: the internet is for porn

------
tonyztan
Just received an email from Glidera, a Bitcoin exchange. This is the first
service to ask me to reset my password. I wonder why Uber, NameCheap, FitBit,
and many others have yet to warn their users? Is Cloudflare downplaying this?

> Hi [Username],

> A bug was recently discovered with Cloudflare, which Glidera and many other
> websites use for DoS protection and other services. Due to the nature of the
> bug, we recommend as a precaution that you change your Glidera security
> credentials:

> Change your password > Change your two-factor authentication

> You should similarly change your security credentials for other websites
> that use Cloudflare (see the link below for a list of possibly affected
> sites). If you are using the same password for multiple sites, you should
> change this immediately so that you have a unique password for each site.
> And you should enable two-factor authentication for every site that supports
> it.

> The Cloudflare bug has now been fixed, but it caused sensitive data like
> passwords to be leaked during a very small percentage of HTTP requests. The
> peak period of leakage is thought to have occurred between Feb 13 and Feb 18
> when about 0.00003% of HTTP requests were affected. Although the rate of
> leakage was low, the information that might have been leaked could be very
> sensitive, so it’s important that you take appropriate precautions to
> protect yourself.

> The actual leaks are thought to have only started about 6 months ago, so
> two-factor authentication generated before that time are probably safe, but
> we recommend changing them anyway because the vulnerability potentially
> existed for years.

> Please note that this bug does NOT mean that Glidera itself has been hacked
> or breached, but since individual security credentials may have been leaked
> some individual accounts could be vulnerable and everyone should change
> their credentials as a safeguard.

> Here are some links for further reading on the Cloudflare bug:

> TechCrunch article: [https://techcrunch.com/2017/02/23/major-cloudflare-bug-
> leake...](https://techcrunch.com/2017/02/23/major-cloudflare-bug-leaked-
> sensitive-data-from-customers-websites/) > List of sites possibly affected
> by the bug: [https://github.com/pirate/sites-using-
> cloudflare/blob/master...](https://github.com/pirate/sites-using-
> cloudflare/blob/master/README.md)

> If you have any questions or concerns in response to this email, please
> contact support at: support@glidera.io

~~~
SnaKeZ
Namecheap: [https://blog.namecheap.com/cloudflare-security-
incident/](https://blog.namecheap.com/cloudflare-security-incident/)

------
StavrosK
I would like to point out that, if most sites used two-factor authentication,
this leak would be at most a minor inconvenience. Maybe we should push for
that more. Just days ago I talked to Namecheap about its horrible SMS-only 2FA
and asked them to implement something actually secure, maybe contact your
favorite site if they don't have 2FA yet.

~~~
almost_usual
If you setup TOTP (Authenticator) while this bug was out in the wild your
shared secret key could have leaked. SMS would actually be safer than TOTP in
this scenario.

~~~
leni536
That's insightful. So you shouldn't only reset your passwords, but your TOTP
setup too (if you set it up in this period).

I think it's a flaw of TOTP though. The client secret should be client
generated and should never leave the device.

~~~
almost_usual
Yes, unfortunately both the client and server need to have that shared private
key to generate the same codes.

Transmitting the key over a 'secondary' channel would have protected people
here.

It begs the question of whether or not TOTP is really 2FA if it is setup using
a single channel of communication.

------
jasonlingx
Do I need to change my cloudflare password?

------
yeukhon
Would Internet Archive able to "cache" the leaks?

------
beachstartup
this is another data point that supports my personal, hare-brained theory that
the expectation of privacy on the internet is simply naive, a fool's errand.
it never existed, and never will.

this is despite (or maybe because) of my best efforts to secure systems as a
major part of my job.

------
djph0826
Volusion.com

------
amq
The title is misleading (for now). It is just a list of all sites using CF,
compromised or not.

~~~
jononor
All sites are compromised. Anything which was in memory, which could be any
site, would be spewed out. Regardless of which site was used as the trigger.

~~~
amq
A quote from the page:

> This list contains all domains that use cloudflare DNS, not just the
> cloudflare proxy (the affected service that leaked data).

------
cromulent
"List of Sites _possibly_ affected"

Sites using Cloudflare, really. However, Cloudflare say that only sites using
three page rules were affected - email obfuscation, Server-side Excludes and
Automatic HTTPS Rewrites. [1]

Is this over-estimating the impact, perhaps?

[1] [https://blog.cloudflare.com/incident-report-on-memory-
leak-c...](https://blog.cloudflare.com/incident-report-on-memory-leak-caused-
by-cloudflare-parser-bug/)

~~~
cstejerean
No! And this is why cloudfare's poor write up continues to confuse people.
Sites with those features triggered the bug. Once the bug was trigerred the
response would include data from ANY other cloudfare customer that happened to
be in memory at the time. Meaning a request for a page with one of those
features could include data from Uber or one of the many other customers that
didn't use those features. So the potential impact is every single one of the
sites using CloudFare. Not over-estimated at all.

~~~
tyingq
The email Cloudflare is sending out to their customers has a pretty "no big
deal" tone as well:
[http://pastebin.com/pUnKJE3J](http://pastebin.com/pUnKJE3J)

I assume there's a separate email for sites where they happened to find Google
cache data, but...

