Hacker News new | comments | show | ask | jobs | submit login

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 of it.

"Trust us" doesn't fly any more, this simply isn't good enough. Sorry, you lost my vote. Not even once

edit: why the revulsion? This bug would have been caught with valgrind, and by the sounds of it, using nothing more complex than feeding their httpd a random sampling of live inputs for an hour or two




>edit: why the revulsion

I'd guess it's because of the crude and reductive way you describe the service cloudflare provides. I don't know what type of programming you do, but many small services don't have the infrastructure to mitigate the kind of attacks cloudflare deals with and they wouldn't be around without services like this.

I don't like the internet becoming centralized into a few small places that mitigate DDOS attacks like this, but I like the alternative (being held ransom by anyone with access to a botnet) even less.

I'm going to take a more even handed approach than what you're suggesting. Any time you work with a service like this you risk these kinds of things - it's part of the implicit cost/benefit analysis humans do every day. I'm not ready to throw out the baby with the bathwater because of one issue. I'm not sure what alternative you're suggesting (I didn't see any suggestions, just a lot of ranting, which might also contribute to the 'revulsion') but it doesn't sound any better than what we have.


So rather than demand fixes for the fundamental issues that enable ddos attacks (preventing IP spoofing, allowing infected computers to remain connected, etc), we just continue down this path of massive centralization of services into a few big players that can afford the arms race against bonnets.

Using services like Cloudflare as a 'fix' is wrecking the decentralized principles of the Internet. At that point we might as well just write all apps as Facebook widgets.


When in a tactical emergency do not say "and why is this shit raining down upon us?"

That is a separate step. First you either take cover or help.


Problem most often is that after you take cover, you forget to ask that question.


Thats not true though


Interesting, so to make people stop thinking strategically and run the way I want, just throw shit at you?

Do you see a problem with that?


However, I haven't seen people enable ButtFlare's proxy only when under DDoS. Most of their users enable the proxying just for the CDN performance or just in case or… you get the idea.


Once your origin is under a DDoS attack, how would Cloudflare's proxy help?


Yeah, it wouldn't help if the attackers don't resolve the DNS hostname on ~every request :D But then, there are ways to find the origin anyway (when buttflare is enabled), someone in this thread posted the real IP address of Hacker News…


You stand up the service somewhere else, and point the cloudflare proxy at that.

Everyone in the "cloud" is able to do the migration even without having prepared a disaster recovery plan ahead of time.


>I'm not ready to throw out the baby with the bathwater because of one issue.

Extreme centralization of the Internet is not a "baby", except maybe in the sense of a cuckoo's egg.

But I'm willing to bet the mentality of this comment is highly representative of many web developers and service providers. They will not seek to fix anything, because they don't see this state of things as a problem in the first place.


How about... stop CLOUD THIS and CLOUD THAT.

Cloud means extreme centralization.

It means giving your data to a third party you don't control.

Why?

Why does our networked software have to assume a centralized topology?

In the days when developed countries had dialup, protocols (IRC, Email, etc.) were all decentralized. Today, all the famous developers live with fancy broadband internet connections and forgot what it's like to have to think about netsplits.

The result... all the software is either "online" or broken.

There shouldn't be an "online" or "offline". There should be "do I have access to server X currently?"

Why do we need Google Docs to collaborate on a document if we are all in the same classroom?

Why do we need centralized facebook server farms whose engineers post on highscalability how they enable us all to post petabytes of photos and comment to our friends?

Why do we need centralized sites to comment at all? Each thread is local to its parent.

Why does India need internet.org from facebook?

If communities could have a network that survives without an uplink to the outside world then DDOS from the global internet would just cut off that network's hosting of documents to outsiders. They'd still be able to do EVERYTHING locally - plan dinners, book a local appointment, send an email etc. and even post things out to the greater internet.

This is a future I want to see.

We already have mesh networks. We need more web based software to run these things.

That's what we are building at qbix.com btw.


Your why questions can all be answered by "It's cheaper than hiring a team to do it in-house". At the end of the day it's all about money and non-techy people are often the people in charge of the money.


Doesn't have to be. Services can be packed into easily deployable package. It's even easier now thanks to container technology.


I agree with you 100%.

Tim Berners-Lee, the "father" of World Wide Web, is currently advocating for exactly what you are asking for.

See: https://www.decentralizedweb.net/


lol, qbix.com connects to cloudflare.com


What are you talking about?


I visited the website you mentioned: qbix.com My add-blocker (ublock) blocked third party resources from cloudflare.com on that website. It's a funny fact after reading your comment in this thread.


You're absolutely right. Cloudflare is a "global active adversary"[1] and has done irreparable harm to the internet at large. This is just a small taste of what's surely to come from CloudFlare's massive influence. They've shown that they cannot be trusted with everyone's data.

[1] https://trac.torproject.org/projects/tor/ticket/18361


Step 0) Obtain black funding from NSA budget to start and "VC invest" in a global CDN company...

(Now I'm trawling Crunchbase to see if I can work out which investors are NSA front companies, then I'm gonna look to see what _else_ them and their partners have invested in...)


Covertly get into a company that terminates ssl for half the internet, and... spill your precious secrets everywhere, instead of siphoning them off silently?


Plausible deniability? "How could we have known the flaw was exploited by NSA and FBI? We didn't know about the flaw at all!" When, actually, it was designed by NSA, before they created CF as an attack vector. Eventually the vuln is discovered as was inevitable, but because the caches were theoretically "public" no one notices all the drone strikes and parallel constructions correlated with CF use.

I don't actually believe that, but it isn't an unreasonable theory.


Not NSA, but the CIA funds and operates In-Q-Tel[1]. They've funded companies like Palantir and Keyhole (which became Google Earth).

[1] https://www.crunchbase.com/organization/in-q-tel


I should have done my research, but I walked away from an accepted offer at a company once I found out they took money from In-Q-Tel.


How do you find stuff like this in general? I would love to limit my business to entities I know haven't dealt with other entities I consider suspect, but I don't know how to actually do this filtering.


Could be a good topic for Ask HN?


"Step 0) Obtain black funding from NSA budget to start and "VC invest" in a global CDN company..."

I once came up with that exact concept for a nation-state subversion. It would even pay for itself over time. I kept thinking back to it seeing the rise of the CDN's and the security approaches that trust them.


Long been rumoured in the more paranoid corners of the web they are intelligence front/partners.


Of course they're intelligence partners, perhaps not wittingly, but Cloudflare was designed from ground up to be one of the most interesting targets for every intelligence agency in the world.

After the Snowden leaks it really seems nonsensical to give Cloudflare the benefit of the doubt and assume that they aren't compromised.


Am I misunderstanding that this would be useful for parallel construction, but that the public failure actually subverts the usefulness of Cloudflare as a MTIM partnering with someone?


"This bug would have been caught with valgrind, and by the sounds of it, using nothing more complex than feeding their httpd a random sampling of live inputs for an hour or two"

Or prevented using abstraction that do bounds checking. Or even just used ragel with a memory safe language and prevented all issues like that from ever happening. Probably would have been less work even with the reimplementation of an http proxy from scratch.


>with a memory safe language and prevented all issues like that from ever happening.

drastically reduced, but not quite ever. For instance, use a GC language, especially in this domain, you might do some data pooling to reduce GC overhead. Maybe you forget to clear data in the pool. Same kind of error can result.

But yes, I feel like security sensitive stuff like this shouldn't be done in C / C++ any more.


They also actively deter Tor use. I've cancelled subscriptions with Cloudflare-hosted sites because they make securely and anonymously browsing their sites a pain.


I'm running a side-project on Cloudflare and it's accessible through Tor without problems. I suspect this comes down to the settings a site owner sets up in their Cloudflare interface. It would stand to reason if for example you applied the highest security setting across the board, Tor and VPN users would get presented with a captcha.


I have been presented with a captcha by cloudflare many times without using tor or a VPN. It is the best way to divert users from your website. My natural reaction is that unless I absolutely need to use this particular website, I move to the next result on google. Websites who use cloudflare are suicidal.


> Websites who use cloudflare are suicidal.

I think you are overestimating the amount of people doing their regular browsing through Tor


Again, I wasn't using Tor or a VPN


Is this made clear in their UI? Do they have something saying "this setting will screw over many VPN users" and "this setting will screw over with all Tor users"? If not, it's in large part their problem as well.


I would say it's "clear" in exactly the same way the privacy slider within the Tor browser is clear. Why not set everything to its max value always? Because there will be limitations arising from it. In the CF interface it's pretty obvious adjusting the settings in that way will increase filtering and captcha challenges for users.

I think the decision that goes on in the minds of most site operators is "fuck convenience and sleazy Tor users, I want my site to be as safe as they can make it".

It's worth noting that other reverse proxy providers I worked with when freelancing expose the very same controls to site owners. Based on anecdotal knowledge, I'd say anonymized users accessing a site behind CF are subject to less hassle than those accessing a site behind something like X4B with comparable settings.


It makes sense that they treat Tor like a probable adversary, but the cost analysis seems really flawed.

Sure, the proportion of requests passing through Tor are more likely to be malicious, but given the bandwidth constraints the adversary seems limited.

The costs aren't only the lost business from people like you, but people who should use Tor giving in. There's some wisdom to people even researching something as mundane as what their dog ingested using anonymized services, much less other medical questions.


CloudFlare is neither the first nor the biggest CDN. I can't recall Akamai having a hole this big. They're either more secure or better at keeping things quiet.


To be fair to CloudFlare, Google had a heap issue a few years back (maybe like 7 now) where internal flags and copies of argv (which Google use heavily for config) were clearly present in output from their HTTP frontends, including references to Borg before Borg was ever documented publicly.

Over in App Engine land, someone bypassed their JVM sandbox and managed to extract a copy of their JVM image, which included much of their revered base system statically linked into something like a 500mb binary.

Sorry, I'd have to go digging to find references to either of these incidents. At least in either case customer data wasn't leaking, but suffice to say it's a little bit of the pot calling the kettle black

And finally let's not forget the China incident, which rumour has it, resulted in a system compromise at Google right to the heart of their engineering organization. Of course they didn't get roasted like Yahoo recently did over their password leak



I'd like to see how much of a mess their argvs are


Launch Chrome on Linux and grep the ps output.


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.


I don't buy this argument.

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.


The only thing the end user has is the difference between http:// and https://. Cloudflare undermines that entirely. How can a user possibly ever know whether it's safe to enter their credit card number or medical information in a web form, in a world where CloudFlare "Flexible SSL" exists?


If a user thinks the presence of "https" means it's safe to enter credit card details or medical information, that's already a huge problem. Yes, "https" should be a prerequisite to entering sensitive information, but that's only part of it; the other part is whether you actually trust the server you're sending that information to. The server could be using ironclad encryption across the whole connection, but that doesn't mean they'll still handle your data safely. Any site that wants sensitive information like this has to do many things to ensure it's secure, and making sure they have a secure connection is only one of those things. If you trust that the server operator has done everything else necessary to keep your credit card details safe, then you should also trust that they're not using Flexible SSL.

Edit: Dear downvoters, can you please explain why you disagree? What I wrote really shouldn't be controversial in the least, so I don't understand the drive-by downvotes.


It's always fairly safe to enter credit card details, you can chargeback that shit, type it wherever you feel like and just claim ignorance when it goes poorly. That's basically the whole point of using a credit card and not your bank account where you're liable for at least some of the money taken.

No company is likely to handle your payment details completely securely. You're relying on it working out on sheer luck most of the time and chargebacks on the rest.


This is why PCI Compliance exists. Part of the requirements of PCI are that you must encrypt transmission of cardholder data across the network. So companies that accept credit card details while using Flexible SSL are presumably violating the PCI DSS. Companies handling small volumes use self-assessment, but larger companies are actually audited annually for this stuff.


It's unfortunate that the actual content of PCI is an incoherent and actively counterproductive mess.


A big part of that incoherence comes the fact that a lot of their guidelines are too broad. For instance, one requirement says all activity performed by an admin must be logged. How many financial companies do this today on every server/device in their PCI environments? My guess is nearly zero, because it's very difficult to find someone who knows what is needed and how to do it correctly, but very easy to avoid even being discovered as being out of compliance.

Then there's the whole lone-auditor thing where a very large data-center or three are being audited by a single person over the course of two weeks, or less. That person is absolutely bombarded with information about an environment that is foreign to them. The end result I think is that so far companies have had it very easy to get by. They only have to pay for a week, or two at most, and whatever limited findings they get are fixed and they move on to the next year.

If companies actually had to live with a slower and more methodical audit, there would be many more findings and a lot more money spent, both on the auditing process and the resulting cleanup. The upshot is this would drive actual innovation in the space of having proper logging, file integrity, encryption, access controls, etc.

The whole audit industry is just.. icky. It needs a massive overhaul and the financials need to be forced to pay for it.


Nice, good to know the credit card companies are doing their best to mitigate their liability due to issues like this too.


> Any site that wants sensitive information like this has to do many things to ensure it's secure, and making sure they have a secure connection is only one of those things. If you trust that the server operator has done everything else necessary to keep your credit card details safe, then you should also trust that they're not using Flexible SSL.

This is true, but conversely there is no legitimate use case for Flexible SSL. Having a datastore like Redis or MongoDB that by default listens insecurely on any address is almost as bad, and such things often compromise the security of a site if it e.g. sends your data across the internet to one of those, but at least there's a more-or-less legitimate use case for that default if it's used on a secured network - it's at least possible that someone using that default isn't deceiving their users. Whereas anyone using Flexible SSL is necessarily deceiving their users (I mean you can argue users might genuinely think "I don't trust my local cafe operator but I do trust the completely public, unsecured internet", but I don't think that's a coherent position for anyone to take).


The use-case for Flexible SSL is when you're not handling sensitive data but still want to offer https:// because really every website should offer it. In fact the blog post that introduced Flexible SSL (https://blog.cloudflare.com/easiest-ssl-ever-now-included-au...) said basically that. The whole point of the feature was it was a simple one-click way to go from http:// to https://.

That said, now that we have Let's Encrypt, and as more tooling gains support for automatically handling that, the value of Flexible SSL is going down, and I do hope they retire it eventually.


> The use-case for Flexible SSL is when you're not handling sensitive data but still want to offer https:// because really every website should offer it.

That's putting the cart before the horse. "Every website should offer" authentication and confidentiality, that's why we want every website to use HTTPS; having a URL that starts with https:// is not a goal in itself.


Flexible SSL still protects the user from being on an untrusted network, from having their ISP read and/or modify their traffic, etc. It's much better than bare http://.

Security is not binary, but you keep treating it like it is. Security is a continuum, and any progress you make towards perfect security is good.


> Flexible SSL still protects the user from being on an untrusted network, from having their ISP read and/or modify their traffic, etc. It's much better than bare http://.

I would strongly dispute the "much". If anything the local network is more likely to be trustworthy than the remote network - people keep talking about cafe wifi, but the user likely knows who's running the cafe wifi and can complain if they start injecting ads etc. Whereas the user has literally no idea who might be on the connection path between cloudflare and the website and listening in, MitMing or anything.

http:// versus https:// is inherently binary; there's no way to display a connection as http⸵:// . If it doesn't mean "encrypted while transiting the public Internet" at least then what does it mean?


Can you think of an existing system (let's go with websites) that meets your standards?


There isn't an automated system that can tell you whether it's safe to give data to a website, just like there's no automated system which can tell you a given vendor/service provider in general is reputable. All you've got is regulations, human-based reputation ranking, and public shaming.


Exactly this. Anytime you give sensitive information to another party you have to evaluate the risk. Having an insecure connection to that party is obviously risky, but that doesn't mean that having a secure connection means there's no risk. Companies that accept sensitive information while using Flexible SSL are probably mishandling your data in other ways too.


> All you've got is regulations, human-based reputation ranking, and public shaming.

Indeed - so we should be applying all of those against CloudFlare, and any other organization that offers or uses a "Flexible SSL"-like product, as firmly as we can.


You seem to be missing the point.

If the company is handling sensitive data, such as credit card information or medical information, there's already regulations to handle that. There's literally no point in trying to add regulations around Flexible SSL specifically, since the usage of Flexible SSL likely already contravenes the regulations for that sensitive data and therefore companies handling that data shouldn't be using it.

If the company isn't handling sensitive data, then again there's no point in adding regulations around Flexible SSL, because what possible benefit would that serve?

Flexible SSL is simply one tool that websites can use. It's intended to be used by sites that would otherwise just be using http://. Sites that do protect more sensitive information certainly could use it, but that would be a bad decision on their part. And we don't need regulations around it specifically, because there's also a million other bad decisions that company could make that would expose that data, and there's really nothing special about Flexible SSL that makes it in particular need of regulation.


Some information might be sensitive for the end user, but not legally protected. Even something as simple as their name or pseudonym can be serious for some people.

I think serving a site over https:// amounts to advertising that information sent to/from that site will not be sent unencrypted over the public internet, and users will use that when deciding what things are or aren't safe to enter into that site. Surely there are regulations that already apply to that? And in any case regulations are only one of the options you mentioned; we should be applying a lot more shame to CloudFlare and anyone who uses "Flexible SSL".


"Cloudflare undermines that entirely. "

In their defense, this is a flaw of the whole SSL/TLS security model. I think even Google did that before Snowden, presented you with https:// urls but proxied everything in clear text (they claim they don't do it now). Still, you can be pretty sure that many https websites might pass traffic in clear text to their backends and not necessary take security even a little bit seriously.


Google at least proxied everything over their own private fiber. Cloudflare proxies it over the public internet on a long route (since they terminate SSL as close to the client as possible).


Private fiber in other people's datacenters. Better I suppose, but not much.


Unencrypted over private fiber and unencrypted over the public internet are worlds apart.


That has nothing to do with using fiber vs internet though.

EDIT: Original comment said he could pull content off Google results. To respond to the new one:

No, they're not worlds apart when you're on the backbone. They still go through other people's datacenters and that's what causes the problem - we're not talking about stuff that goes over wifi or corporate networks here - we're talking generally just big ISPs in both cases.


> A site using Flexible SSL is no less secure than one using http://,

It can be, in several ways. Most critically, it stops browsers from detecting the connection as insecure and applying mitigations.


Beyond Secure cookies, what mitigations are you thinking of? Secure cookies don't count because serving Secure cookies over Flexible SSL is no less secure than serving regular cookies over http://.


In addition to limiting certain browser features to HTTPS sites, browsers now also warn about submitting passwords over HTTP and mark pages that do so as insecure.

Browsers also prevent HTTPS sites from embedding active content from HTTP sites.


Many browser features (like location API) are gradually being deprecated from plaintext HTTP.


Interesting. I hadn't heard of that before. Looks like it's just Chrome doing this?


And Firefox


Disagree. The point is that when people see that lock that tells you your connection is secure, when it's actually not, that causes more damage than if your connection was actually not secure (because then presumably you wouldn't be typing in credit card numbers and other sensitive info if you saw http:// in your address bar).



Yeah, if you're capable of MITMing traffic between CloudFlare and the server, you're most likely capable of stealing emails or HTTP requests to the server anyways and generating your own certificate for them anyways. It's a security loss, but probably a minor one.

The reality is, you're much more likely to get sniffed on public wifi or even your school or workplace network than someone running the server in a datacenter is, generally speaking if someone can sniff them at a DC they can do much more already. So it's still a respectably huge security gain for users.

And they do offer a good way to secure this connection too where you can do full SSL and use a certificate signed by them.

Would you be more comfortable if they offered another way to represent this to the browser? An X-Endpoint-Insecure header or something like that?


> Would you be more comfortable if they offered another way to represent this to the browser? An X-Endpoint-Insecure header or something like that?

Yes, definitely, _Cloudflare_ should own this and push it through. You know they won't though because that would inconvenience their customers.


I'd be more comfortable if they didn't lie about security to site visitors. "Configure a self-signed cert on your hosts so we can encrypt the traffic" is a low bar to clear.


To my sibling: the issue is that people can and do consider Flexible SSL "good enough", when it really isn't. It gets you the green lock and the warm fuzzies, but the page just isn't secure. A false sense of security is worse than no security, because no security at least is glaringly obvious.


But it is secure. It's secure against the user being on an untrustworthy connection, it's secure against their ISP deciding to MitM their traffic, and it's also ~~secure against anyone passively sniffing the traffic between the website server and CloudFlare~~ (EDIT: No it's not, see [1]). The only thing it's not secure against is someone in a privileged network position who can MitM the connection between the website and CloudFlare.

So no, it's not 100% secure, but it's far far better than having an unsecured http:// connection.

As for the green lock, you can blame that on Chrome. I have no idea why they insist on using a green lock and green "Secure" text for DV certs. Safari only uses a green lock / green text for EV certs, which is a lot better (and I don't know offhand what Firefox or Edge do). Of course, you could have an EV cert and still use Flexible SSL, but anyone who cares enough to get an EV cert should know better than to use Flexible SSL anyway, and there's a great many ways to make your server insecure, using Flexible SSL is very far from the worst way.

All that said, it would be great if CloudFlare would just stop offering Flexible SSL in favor of the self-signed CSR approach. Any CloudFlare customer who can create their own cert to talk to CloudFlare can also create a CSR to get a cert from CloudFlare just as easily, so it's not clear to me why they still even offer Flexible SSL.

[1]: I thought Flexible SSL was the option to use an arbitrary self-signed cert on the origin server. gkop pointed out that, no, Flexible SSL means no encryption at all.


Actually, it is worse than just using plain HTTP because it tricks people into believing their connections are secure. There is a significant and growing group of lay people who have been trained not to input sensitive data into nonTLS web pages. "Flexible SSL" effectively screws them.


> it's also secure against anyone passively sniffing the traffic between the website server and CloudFlare

How is it secure? CloudFlare allows you to send this traffic in the clear. If they required this traffic be HTTPS, that would be far better for web security.


My bad. I thought Flexible SSL was the option where you can use any arbitrary self-signed cert. But you're right, Flexible SSL means no encryption at all between the origin server and CloudFlare. I will edit my post accordingly.


What if the origin server forces https on the link between CF and the origin server?


That would be much better. Also Cloudflare gives an option to require HTTPS on this link. What's so sneaky about Cloudflare is they call the insecure option "Flexible SSL" rather than what it is, "Insecure SSL". And a major issue is that the end user has no way of knowing the site's Cloudflare configuration and whether it is secure or not.


There is absolutely no reason to use an EV cert other than to line the pockets of certificate companies. I have never once seen users actually check the details of an EV cert or freak out they have a regular https connection.

When observing non-technical users, I still see people clicking through blatant full page cert errors after connecting to WiFi because they've been implicitly trained that it's the captive portal making them sign in.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: