Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

List of Sites Affected by Cloudflare's HTTPS Traffic Leak

github.com

Post reply on HN
Print view View original

121–130 of 228 posts

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#121

Post by philsnow »

almost_usual wrote: post #34
StavrosK wrote: post #28

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.

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.

What ? No, that shouldn't be possible (unless the site operator massively fucked up, or there's some attack that feasibly lets you go from one or more TOTP values to the likely shared secret).

TOTP works by having (as you said) a shared secret key, and both sides calculate an HMAC of the secret along with the timestamp, and then just modulo the resulting HMAC by 10^6 (usually, for TOTPs with six digits).

Your google authenticator (or whatever) app does this HMAC on the shared secret + time, you type in six digits, and the other side does the same HMAC and verifies that they're the same. If they're UX-conscious, they might decide to HMAC the previous and next 30 second periods as well and compare those too, to account for small amounts of time skew.

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#122

Post by CrLf »

vmarsy wrote: post #114

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…

It seems the parser is implemented as an nginx module, thus having access to its memory. CloudFlare terminates SSL in nginx and establishes SSL connections to their upstreams, but inside nginx everything is cleartext.

Private keys are not exposed because they are not stored locally (they use the Lua module to implement this).

Of course, AFAIK.

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#123

Post by detaro »

philsnow wrote: post #121
almost_usual wrote: post #34

Earlier quoted context omitted.

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.

What ? No, that shouldn't be possible (unless the site operator massively fucked up, or there's some attack that feasibly lets you go from one or more TOTP values to the likely shared secret). TOTP works by having (as you said) a shared secret key, and both sides calculate an HMAC of the secret along with the timestamp, and then just modulo the resulting HMAC by 10^6 (usually, for TOTPs with six digits). Your google…

parent said "if you setup TOTP". If you did that, you somehow communicated the shared secret key to your authenticator, presumably from a web page. Which could have leaked.

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#124

Post by leni536 »

jitbit wrote: post #88

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

> At least change the cookie name

This is bad advice, you should invalidate the tokens, that's it.

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#125

Post by AGKyle »

microtonal wrote: post #13
chrisbolt wrote: post #9

Earlier quoted context omitted.

Is your password manager 1Password? https://blog.agilebits.com/2017/02/23/three-layers-of-encryp...

Even if your password manager is not compromised, the credentials of so many sites is potentially leaked that you should probably still update a substantial number of passwords. I hope 1Password's Watchtower service will soon give hints.

Disclaimer: I work for AgileBits, makers of 1Password.

I am combing through site lists trying to find sites that are impacted. However, I am only updating based on sites that have suggested that they be updated. Very few are suggesting password updates right now. But, there are a few that are in Watchtower now.

Lists like the one this link to are useful, but they don't actually say if a site was indeed impacted. In the end we may just treat this like Heartbleed and suggest they all get updated but for now, we're trying to only suggest it where necessary.

If you're aware of any that have suggested password changes please let me know and I'll get them added immediately :)

Kyle

AgileBits

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#127

Post by petters »

rmaurin wrote: post #95
pyre wrote: post #71

Earlier quoted context omitted.

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

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.

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?

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#128

Post by ecnahc515 »

dugmartin wrote: post #117
vmarsy wrote: post #114

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…

My guess given their widespread use of Go is that each parser was a goroutine which uses the same process heap as other goroutines parsing other page requests.

Have you read their incident response? If you had, you would know they weren't using Go for this and it was actually an issue an a parser generated by ragel (C++) which was then used as an nginx module.

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#129

Post by cortesoft »

jitbit wrote: post #88

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

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.

Re: List of Sites Affected by Cloudflare's HTTPS Traffic Leak

#130

Post by new299 »

ig1 wrote: post #118

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

That seems like a reasonably unwise thing to say. It would be absolutely reasonable for someone to change there passwords after breach.

By citing a personal view point they're seeking to downplay the issue while providing little useful advice.

Post reply on HN