21–30 of 1001 posts
> Many of the logged urls contained query strings from https requests that I don't think they intended to share. I guess this confirms a few things. - The complete query strings are logged, - They don't appear to be too concerned with who accesses the logs internally or have a process that limits the access, and - They're willing to send those logs out to a random person.
How does such a simple bug not get picked by auto tests, ci or end to end tests? I am baffled. Since we are behind cloudflare, I am not sure what I should tell my manager now. I lack the technical know how to parse that extremely technical article. Are we supposed to just assume all our traffic that passed via cloudflare is possibly compromised? It's also a bit sad that travis has to contact cloudflare by twitter. Se…
As for what you should do: it sounds like the impact is relatively low. I'd personally change easily-changed secrets which go over the session, and potentially externally facing customer passwords (yes in enterprise, maybe not in consumer).
(I don't have any insider info on this breach, though, but I read both posts and know how the system works.)
Step 1) MITM the entire Internet, undermining its SSL infrastructure, build a business around it Step 2) leak cleartext from said MITM'd connections to the entire Internet I recently noted that in some ways Cloudflare are probably the only entity to have ever managed to cause more damage to popular cryptography since the 2008 Debian OpenSSL bug (thanks to their "flexible" ""SSL"" """feature"""), but now I'm certain o…
Step "What does secure mean anyway") SSL terminate even sites that are not sending data to Cloudflare securely
I think this bug is kind of an indictment of Ragel. It has some great ideas, but since the generated code is so low level - and allows arbitrary blocks of code to be executed in the guts of the parser, bugs like these can result in this horrible memory issues - particularly since the generated code is often used to parse untrusted user input.
Full details from Cloudflare: https://blog.cloudflare.com/incident-report-on-memory-leak-c...
How does such a simple bug not get picked by auto tests, ci or end to end tests? I am baffled. Since we are behind cloudflare, I am not sure what I should tell my manager now. I lack the technical know how to parse that extremely technical article. Are we supposed to just assume all our traffic that passed via cloudflare is possibly compromised? It's also a bit sad that travis has to contact cloudflare by twitter. Se…
I don't think he had to, but he got an answer in minutes. I don't think that's the part to be worried about. As for what you should do: it sounds like the impact is relatively low. I'd personally change easily-changed secrets which go over the session, and potentially externally facing customer passwords (yes in enterprise, maybe not in consumer). (I don't have any insider info on this breach, though, but I read both…
"We've discovered (and purged) cached pages that contain private messages from well-known services, PII from major sites that use cloudflare, and even plaintext API requests from a popular password manager that were sent over https (!!)."
The trouble is you have no way to know if someone discovered this earlier, and harvested info for a long time.
Or, how much harvested info from your site might be in a Google cache for someone else's site.
Our CNAME pointing to github pages was down on Cloudflare today with a 1014 error. I'm guessing they broke some other stuff while scrambling to fix this privacy issue? Not a good day for them.
Nothing on their status page about it though :|
Earlier quoted context omitted.
Step "What does secure mean anyway") SSL terminate even sites that are not sending data to Cloudflare securely
Yup, this made it crystal clear, years ago, that Cloudflare's business incentives were and are at odds with a secure web.
A site using Flexible SSL is no less secure than one using http://, and in fact is more secure, because nobody can MitM the connection between CloudFlare and the end user. The only thing vulnerable is the connection between the website and CloudFlare (~~and only to MitM, not to passive sniffing~~ EDIT: this isn't true, see [1]), but that's a much smaller and much better-protected surface area.
Now it's quite obvious that the alternative SSL options are much better because they secure the data properly the whole way. But claiming that Flexible SSL is somehow undermining the security of the web is extremely hyperbolic.
[1]: The connection between the origin server and CloudFlare can in fact be passively sniffed. I thought Flexible SSL was the option to use an arbitrary self-signed cert, but it actually means no encryption.
> Many of the logged urls contained query strings from https requests that I don't think they intended to share. I guess this confirms a few things. - The complete query strings are logged, - They don't appear to be too concerned with who accesses the logs internally or have a process that limits the access, and - They're willing to send those logs out to a random person.