> In the control panel for DNS setup you have an option called "Firewall", and within that option there is a setting called "Security level".
> By default it is set to "Medium", which means that a lot of people will be blocked from your website by a very annoying and time consuming CAPTCHA. And the problem with this option is that it cannot be disabled in the free service. You actually has to pay for the Enterprise edition, which is more that 200 dollars a month per domain, in order to disable the feature. Even if you set the setting to the lowest available value in the free service, which is Essentially off, many of your visitors will still be blocked.
> Your connection is only really encrypted up until the CloudFlare servers, after that the connection can simply be clear text. The connection is encrypted between the browser and CloudFlare, and between CloudFlare and the website if the website has a SSL certificate, but the communication in-between remains completely visible to CloudFlare.
> It means that sensitive data is being disclosed to CloudFlare without the consent or knowledge of your visitors.
> Your connection is only really encrypted up until the CloudFlare servers, after that the connection can simply be clear text. The connection is encrypted between the browser and CloudFlare, and between CloudFlare and the website if the website has a SSL certificate, but the communication in-between remains completely visible to CloudFlare.
That is a really interesting point.
When you install your SSL certificate on Cloudflare and point your DNS at them, you are essentially installing Cloudflare as a "man in the middle" between your visitors and your server.
Even if you have SSL between Cloudflare's servers and your in-house servers, there is technically still a point where Cloudflare terminates the SSL and can see all the traffic in plain text before they forward it on to your own servers.
That is a lot of trust to be putting in Cloudflare!
To be fair, though, it's just like working with any third party cloud provider. If you host on AWS, for example, you better believe sysadmins at AWS could look at all of your traffic, too, if they wanted to.
So no matter what you do, if you host in the cloud at scale instead of owning your infrastructure, you have to trust third parties.
Cloudfare as an SSL "MITM" was exactly what the portuguese authority responsible for running this year's census did! They then acted offended and made completly false assurances when this was pointed out. The privacy authority promptly forced them to change back.
eh.. "it's just like working with any third party cloud provider" - not exactly.
most cloud providers have not posted that they will actively scan what your visitors read and write to send info to three letter agencies so that men with guns can decide if freedoms you or your visitors have had should continue.
It's even more interesting that the ssl and encryption stuff is so confusing that even tech focused professionals do not know it's possible - just because cloudflare is the dns used.
I guess that really means that the little lock icon in the url bar is a very false sense of whatever for 18% of the web.
run into "You actually has to pay for the Enterprise edition" a couple of times for what I considered trivial things.
recently trying to ban ip blocks from some bad actors, found I can't get their actual ip in my raw access logs. The really bad people just show up as cloudflare ips in the logs.
So I find a cpanel plugin that is to help, but it was once promoted by cloudflare and no longer supported. There is now some command line thing that needs install and some nano/vim to add cloudlfare things into it.. after a few rounds of trying to piece this together I found it much faster/simpler to disable cloudflare.
'CF-Connecting-IP' request header provides the client (visitor) IP address (connecting to Cloudflare) to the origin web server[1]. Works in the free version.
Besides Cloudflare panel (firewall) also shows IP addresses, And the bad faith actors can be blocked through that via rules. This works in the free version too.
I feel like the blog author understood TLS termination just fine. They just think that you can solve the same problems as CloudFlare without being actively hostile to privacy.
Cloudflare captchas mean I go back to DDG, and once more wish for a browser plugin that removes href attributes to specified sites, so I don't make the same mistake twice.
I'm not feeding a fucking robot just to look at a page.
Didn't Cloudflare have some sort of plugin that would bypass captchas if you set it up once ('proving' you're human)? Any use this plugin? How is it in practice?
Yeah, sorry, it isn't Cloudflare's fault that TOR traffic tends to be malicious. If you want to use TOR but be treated as a respectable peer, get the TOR team to find a way to shut down all the illicit stuff they currently enable.
Very true. If you're running a business that accepts credit cards then it's completely negligent to not block TOR traffic. A lot of credit card fraud comes from people using TOR if you leave that open.
It's arguably negligent to not block TOR traffic from your payment page. People should otherwise be able to read at least the static parts of your site from TOR.
"TOR traffic" is as undesirable as regular traffic, no more no less. From first-world perspective, this maybe skewed towards TOR, but elsewhere TOR is used as everyday, lifeline resource.
From data volume perspective, maybe you are correct. From number of users perspective, I do not believe so.
>If you're running a business that accepts credit cards then it's completely negligent to not block TOR traffic.
Blocking a set of known bad exit relays should be blocked. TOR in general, no.
Lots of businesses taking payments online get the overwhelming majority of their sales from visitors with a "first-world perspective". It can make complete sense to blanket-ban TOR and other signs of bad actors at a cost of 0.1% of your sales (not an unlikely figure).
I like the idea of an open free-for-all Web, too, but I don't expect businesses to stop doing this, given the incentives in play.
Someone created a bogus account using my email trying to claim DNS administrative rights for all domains associated with that email (yeah, yeah, yeah - I should have had domain privacy for everything ... but some didn't)
Cloudflare ended up getting listed as authoritative DNS in its own DNS resolver (even though the registrar's records were supposed to be authoritative)
The only reason they couldn't fully steal DNS settings was I had 2FA enabled with my registrars and on my email account
Took nearly 3 days to claim the malicious Cloudflare account via password resets to my actual email address and enable 2FA on it to my authentication tools
Took another week+ to delete all attempted DNS registries and get Cloudflare to not recognize themselves as authoritative DNS resolution for the domains
And over a month for tech "support" and "legal" to finally get around to responding to my complaints basically saying, "you should have created an account with us with that email so no one else could try to steal it"
If their 8.8.8.8 resolver was returning results from customer accounts that weren't verified, like the GP seems to imply, that seems like a huge security problem.
I do wish that Cloudflare let me know how many visitors are getting a captcha for "Essentially Off". I run a static site so I really don't care much about a few requests. But I do value the CDN.
The criticism regarding Cloudflare as an MITM is odd:
> The connection is encrypted between the browser and CloudFlare, and between CloudFlare and the website if the website has a SSL certificate, but the communication in-between remains completely visible to CloudFlare.
This critique applies to all content delivery networks. CDNs can't deliver content if they can't see the request and response. That visibility is a problem in certain use cases, but in those cases you simply shouldn't use a CDN.
I'm not sure the claim about recaptcha is (or was) correct.
In my whole life, I have been hit with maybe 2-3 recaptcha before accessing a website.
They probably upgraded the system since then, but still, feels like the author is just pissed without any good reason. (actually I would have expected a mention about google collecting data with this but it's not even mentioned)
It really dependa of your ip. If you're in a block that has a bad rep, you'll have the captcha every single time. This seems legitimate but this is definitely not applied per ip, it's apply per ip block.
I have a server that i rented for more than 10 years now, used only as a mail server and a vpn endpoint, i get captcha everytime when I use my vpn.
Now, for someone who lives in a country where ISPs have a bad rep, this makes part of the web horrible. People are then considered as bad actors by default with no way to improve their experience.
Yup. Personally, I'm constantly being hit by CAPTCHAs. For some inexplicable reason, I sometimes have to solve several (5 or 6?) in a row before a site will let me in.
you're much likely behind a CGNAT on a ipv4 connection. I had such a situation once (using mobile) and it was horrible, popular websites won't let me register and all.
Wow. I haven't had an ISP that used CGNAT in a long time, but something vaguely related is probably happening. Maybe I occasionally get assigned IPs that are on some sort of abuse list...
> Another option, if you're running at a larger scale, is to purchase mitigation appliances and just set up your own mitigation infrastructure. This will not be cheap and require some serious connectivity, but beyond a certain point it'll be more cost-effective.
How many companies reach this level? 99% of companies will have to rely on a CDN provider for this.
> You'll want to avoid anything HTTP-specific (as it will be prone to the same privacy issues as CloudFlare), and opt for layer 3/4 mitigation only.
Of course your CDN provider will be more effective if it can inspect unencrypted traffic. So, again, either you are at the level of traffic of a big IaaS provider, or like 99% of CDN customers you choose between letting your provider inspect your traffic or not be protected against app-level DDoS.
> Even something relatively simple like ModSecurity will cover a wide array of problems.
Everything is a question of measure. How much is "a wide array of problems"? How much is "some serious connectivity"?
A middle-ground would be using a CDN to protect against L3/L4 volumetric attacks, without TLS interception. And using ModSecurity or another WAF against application-level attacks. But the result will probably not be as good as applicative protection at CDN level, and will cost you more (you pay for the CDN, for your own WAF infrastructure, and for your 24/7 team ready to write new protection rules when a new attack occur).
Yes of course. The dynamic part of your site will still need protection, though. And if you offload static assets to a third-party, you'll have smaller pipes for non-static data, thus you are less likely to handle a DDoS. So you'll still need someone to protect your non-static data.
45 comments
[ 3.0 ms ] story [ 113 ms ] thread> In the control panel for DNS setup you have an option called "Firewall", and within that option there is a setting called "Security level".
> By default it is set to "Medium", which means that a lot of people will be blocked from your website by a very annoying and time consuming CAPTCHA. And the problem with this option is that it cannot be disabled in the free service. You actually has to pay for the Enterprise edition, which is more that 200 dollars a month per domain, in order to disable the feature. Even if you set the setting to the lowest available value in the free service, which is Essentially off, many of your visitors will still be blocked.
> Your connection is only really encrypted up until the CloudFlare servers, after that the connection can simply be clear text. The connection is encrypted between the browser and CloudFlare, and between CloudFlare and the website if the website has a SSL certificate, but the communication in-between remains completely visible to CloudFlare.
> It means that sensitive data is being disclosed to CloudFlare without the consent or knowledge of your visitors.
That is a really interesting point.
When you install your SSL certificate on Cloudflare and point your DNS at them, you are essentially installing Cloudflare as a "man in the middle" between your visitors and your server.
Even if you have SSL between Cloudflare's servers and your in-house servers, there is technically still a point where Cloudflare terminates the SSL and can see all the traffic in plain text before they forward it on to your own servers.
That is a lot of trust to be putting in Cloudflare!
To be fair, though, it's just like working with any third party cloud provider. If you host on AWS, for example, you better believe sysadmins at AWS could look at all of your traffic, too, if they wanted to.
So no matter what you do, if you host in the cloud at scale instead of owning your infrastructure, you have to trust third parties.
most cloud providers have not posted that they will actively scan what your visitors read and write to send info to three letter agencies so that men with guns can decide if freedoms you or your visitors have had should continue.
It's even more interesting that the ssl and encryption stuff is so confusing that even tech focused professionals do not know it's possible - just because cloudflare is the dns used.
I guess that really means that the little lock icon in the url bar is a very false sense of whatever for 18% of the web.
recently trying to ban ip blocks from some bad actors, found I can't get their actual ip in my raw access logs. The really bad people just show up as cloudflare ips in the logs.
So I find a cpanel plugin that is to help, but it was once promoted by cloudflare and no longer supported. There is now some command line thing that needs install and some nano/vim to add cloudlfare things into it.. after a few rounds of trying to piece this together I found it much faster/simpler to disable cloudflare.
Besides Cloudflare panel (firewall) also shows IP addresses, And the bad faith actors can be blocked through that via rules. This works in the free version too.
[1]https://support.cloudflare.com/hc/en-us/articles/200170986-H...
and
"I don't understand tls termination"
Lots of people don't and that can create a serious problem when someone else is doing it. It's not unreasonable to have it in a cons list.
Also the cloudflare captchas absolutely suck. That's a huge con and you really shouldn't put up with it.
I'm not feeding a fucking robot just to look at a page.
"TOR traffic" is as undesirable as regular traffic, no more no less. From first-world perspective, this maybe skewed towards TOR, but elsewhere TOR is used as everyday, lifeline resource.
From data volume perspective, maybe you are correct. From number of users perspective, I do not believe so.
>If you're running a business that accepts credit cards then it's completely negligent to not block TOR traffic.
Blocking a set of known bad exit relays should be blocked. TOR in general, no.
I like the idea of an open free-for-all Web, too, but I don't expect businesses to stop doing this, given the incentives in play.
Cloudflare ended up getting listed as authoritative DNS in its own DNS resolver (even though the registrar's records were supposed to be authoritative)
The only reason they couldn't fully steal DNS settings was I had 2FA enabled with my registrars and on my email account
Took nearly 3 days to claim the malicious Cloudflare account via password resets to my actual email address and enable 2FA on it to my authentication tools
Took another week+ to delete all attempted DNS registries and get Cloudflare to not recognize themselves as authoritative DNS resolution for the domains
And over a month for tech "support" and "legal" to finally get around to responding to my complaints basically saying, "you should have created an account with us with that email so no one else could try to steal it"
This sounds like they had your password?
Like, when you are CF big you can't just start resolving domains however you feel because folks use your DNS service.
free markets!
/s
But Cloudflare still let them start making DNS entries
Cloudflare (at least at the time) would let you create an account and start doing stuff without verifying you actually owned the email address
Fat-finger? bob[at]bob[dot]com to bon[dot]com? No worries
Enter my email instead of yours? Go for it
It's just a login...right?
> The connection is encrypted between the browser and CloudFlare, and between CloudFlare and the website if the website has a SSL certificate, but the communication in-between remains completely visible to CloudFlare.
This critique applies to all content delivery networks. CDNs can't deliver content if they can't see the request and response. That visibility is a problem in certain use cases, but in those cases you simply shouldn't use a CDN.
In my whole life, I have been hit with maybe 2-3 recaptcha before accessing a website. They probably upgraded the system since then, but still, feels like the author is just pissed without any good reason. (actually I would have expected a mention about google collecting data with this but it's not even mentioned)
Now, for someone who lives in a country where ISPs have a bad rep, this makes part of the web horrible. People are then considered as bad actors by default with no way to improve their experience.
How many companies reach this level? 99% of companies will have to rely on a CDN provider for this.
> You'll want to avoid anything HTTP-specific (as it will be prone to the same privacy issues as CloudFlare), and opt for layer 3/4 mitigation only.
Of course your CDN provider will be more effective if it can inspect unencrypted traffic. So, again, either you are at the level of traffic of a big IaaS provider, or like 99% of CDN customers you choose between letting your provider inspect your traffic or not be protected against app-level DDoS.
> Even something relatively simple like ModSecurity will cover a wide array of problems.
Everything is a question of measure. How much is "a wide array of problems"? How much is "some serious connectivity"?
A middle-ground would be using a CDN to protect against L3/L4 volumetric attacks, without TLS interception. And using ModSecurity or another WAF against application-level attacks. But the result will probably not be as good as applicative protection at CDN level, and will cost you more (you pay for the CDN, for your own WAF infrastructure, and for your 24/7 team ready to write new protection rules when a new attack occur).