This part seems pretty pertinent to this site considering its political nature:
Cloudflare poses a huge risk by completely breaking the TLS/SSL chain used by browsers by setting itself up as a man in the middle. Cloudflare doesn’t do actual DDoS protection, they just make the request to the origin server for you. Once they have received the data, they decrypt it and re-encrypts it with their own certificate. This means that Cloudflare has access to all requests in plain text and can optionally modify the data you see. TLS/SSL is meant to prevent this very issue, but Cloudflare seems to care very little.
If we would consider Cloudflare to be a benevolent entity and surely never modify any data ever, this is still an issue. Much data can be mined from the plain text communications between you and the origin server. This data can be used for all kinds of purposes. It is not uncommon for the USA government to request a massive amount of surveillance information from companies without the companies being able to speak up about it due to a gag order. This has become clear once more by the subpoena on Signal. It should be clear to anyone that end-to-end encryption has to be a standard and implemented properly. Cloudflare goes out of its way to break this implementation.
Considering that this site uses Cloudflare, I don't think it would be great if the feds could intercept all of our passwords and impersonate us.
Not really, it' just pointing out how dumb Cloudflare is. It's nothing new. Obviously if you want end to end security you wouldn't use a service like Cloudflare.
These findings are not anything new. They have been around for the better part of a decade. That does not change the fact that this site's present usage of Cloudflare is dangerous however or that these findings may come as a shock to some.
I didn't realize hexbear used Cloudflare. That's kinda cringe. Guess I didn't read the post close enough or thought that couldn't be the case.
Cloudflare is awful and all that but do they actually get to see all the data between the user and the site or is it the initial request? Maybe a comrade can shine more light on this
If you go into the network tab of the developer menu (inspect element) of your browser and then click around the site, you will see a bunch of requests pop up. If you click on any one of them and look at its headers, you will see the headers in the response: https://hexbear.net/pictrs/image/4pMZxhYszm.png
If we were connecting directly to the Hexbear servers (which we are not, we are connecting to them through Cloudflare), TLS (the encryption protocol that HTTPS uses) should make it impossible to view or edit any of the contents of the data sent between the servers. Yet here we clearly see that Cloudflare has added some new data in the form of HTTP headers. This must mean that Cloudflare can intercept and edit the contents of the requests and responses. In effect, Cloudflare is MITMing the connection.
If you have ever seen a Cloudflare "checking your browser" screen you would already know this, as it is impossible for Cloudflare to show you that page without intercepting and editing the data in the connection.
In conclusion, yes, Cloudflare can really see all (this includes your passwords in plaintext!) the data between the user and the site, after all, you're not even connecting to the site: you're connecting to Cloudflare which then makes requests to the site on your behalf.
Wouldn't this require you to give Cloudflare your cert, as a site admin?
No. Because the thing is: you're not connecting to the Hexbear servers at all; you're connecting to Cloudflare which then (decrypts your request) makes requests to Hexbear's servers (and then decrypts the response to send back to you) on your behalf. Since you're not connecting to Hexbear's servers at all, the status of its cert is completely irrelevant.
My understanding is that a site user's browser will ask for the cert and validate it before setting up a TLS session. The order would be domain -> resolved to IP -> ask for and check cert -> sign session request with cert public key -> server sets up TLS session. I've never used Cloudflare, but I assume it operates by setting up your DNS records to point to their servers and you set up proxy things on your Cloudflare account.
Cloudflare would need to furnish a Hexbear.net cert, according to my possibly flawed logic. The part where I get confused is how that could work, have mitm, and not have Cloudflare have the private key. If it's just proxying the initial cert request, it won't have the private key (it's only on the server in this scenario) so it can't decrypt. To decrypt, it needs to have a provided hexbear private key or be handling all of TLS itself, providing its very own cert for hexbear.net, with Hexbear not handling TLS to users at all. Instead, it might implemented TLS just for hexbear<->Cloudflare connections when requests are sent between them. I must be going wrong somewhere.
Sorry if this is tedious or doesn't make sense and thanks for your patience!
https://hexbear.net/pictrs/image/J7pX1oJx8s.png
Cloudflare owns the cert to hexbear.net
Ah. That seems very bad. Thank you for noticing this and for bearing with me!
This seems bad but I mean I’m sure most of us are heavily compromised. They know you folks.
Even considering your false premise of "no Cloudflare = no site", it would legitimately be better to have no site than a compromised site considering this site's political nature.
This site routinely advocates for the overthrowing of the American government. It would be very unwise to use an American company's service while doing so.
And it is not like if this site was without Cloudflare, there'd be no site. There are plenty of actual anti-DDoS services that actually filter out DDoS attacks. This point is even refuted in the linked article:
Cloudflare is hailed by many as a gratis DDoS protection service, and they advertise themselves as such. However, Cloudflare does not offer DDoS protection, they simply act as a pin cushion to soak the hit. Real DDoS protection works by analyzing traffic, spotting unusual patterns and blocking these requests. If they were to offer real DDoS protection like this, they would be able to tunnel TLS/SSL traffic straight to the origin server, thereby not breaking the TLS/SSL chain as they do right now.
It should also be noted that this gratis "protection" truly gratis either. If your site gets attacked for long enough, or for enough times in a short enough time frame, you will be kicked off of the gratis plan and be moved onto the "business" plan. This requires you to pay $200 per month for a service that does not do what it is advertised to do. If you do not go to the business plan, you will have about the same protection as you would have without it, but with the addition of ruining the privacy and security of your visitors.
And in this article which is linked in the linked article, it goes into further detail how Cloudflare doesn't even protect against DDoS attacks:
At this point, you might be wondering "well okay, I get that, but why should I care as long as it protects my site?", and the answer to that would be: because it doesn't. You can't protect the rest of your infrastructure (mailservers, chat servers, gameservers, and so on), and even for your web-based services, CloudFlare will kick you off the Free and Pro plans if you get attacked too much and they can figure out that you are the target.
In other words: unless you pay them $200/month, they won't provide any protection that you wouldn't already have anyway. And if you do pay them $200/month, you'll get half-functional protection for a single protocol on a single domain, with all your users being completely exposed to CloudFlare and whatever other organizations might obtain access to their traffic or servers. As you'll see below, this is a pretty shitty deal, and there are far better options today.
Cloudflare will literally kick you off their service and gouge you for money if you get attacked for long enough. This is not DDoS protection, this is literally giving in to the DDoSers! And even worse, they're gouging you for money while failing in their initial purpose!
Meanwhile: there are actual DDoS mitigation services that actually do what they are supposed to do:
DDoS mitigation
Use a real (network-level) mitigation provider.
Some providers include mitigation for free with your hosting service (OVH, Online.net, ServerCrate, ...). Others charge a small fee, typically between $1 and $5 (RamNode, BuyVM, SecureDragon, ...).
There are also dedicated mitigation providers for more demanding usecases (Akamai, Level3, Voxility, CNServers, Sharktech, ...) and some providers that resell and/or combine these services (eg. X4B.net).
If you have your own physical infrastructure, you can also pick a mitigation appliance provider. There are quite a few.
And if you must use a Cloudflare-esque Varnish-as-a-service service, then please at least use something not located in the US (or any Five Eyes country (Australia, Canada, New Zealand, United Kingdom, United States) for that matter)! If you really must, then I would recommend using DDoS-Guard which is based in Russia and offers pretty much identical services to Cloudflare.
TL;DR: All of the "problems" solved by Cloudflare are solved better and more efficiently by other services. Use them instead.
Dear Cloudflare: please lick my sweaty taint thoroughly so you can describe its flavor to the FBI
Cloudflare started as a "honeypot" http://www.crimeflare.org:82/honeypot.html https://www.projecthoneypot.org/cloudflare_beta.html
Cloudflare is also a "trusted DNS over HTTPS" service on Firefox for US users. https://support.mozilla.org/en-US/kb/firefox-dns-over-https Unfortunately, that means that they can be easily controlled by US government, so if US government wants DNS lookup logs for millions of Firefox users, they don't have to go to more than one ISP, they can just go to Cloudflare.
Tools to check if website is behind Cloudflare: https://suip.biz/?act=iscloudflare http://www.doesitusecloudflare.com/ (not sure if this one works properly)
more info: https://miloserdov.org/?p=1362 https://www.tyil.nl/post/2017/12/17/on-cloudflare/
