I like how this is published by Cloudflare, who is literally the biggest TLS interceptor in history -- their entire business model is based around MITMing connections.
If I was a group who needed to get eyes on TLS traffic without it looking too suspicious, offering free reverse-proxy services would be the way to go (for attack protection and CDN-like features, of course).
To be fair, Cloudflare don't intercept TLS unless you, as a customer of theirs, specifically ask them to. You can use Cloudlfare for lots of services without having your TLS traffic intercepted by them.
Maybe not TLS, but Cloudflare does mirror and intercept traffic meant for third party non-customer domains when a customer domain decides they want to use cloudflare's AMP service. This is done in the name of 'faster' access. But really it's just cloudflare mirror your domains and serving them up so you never see the hits coming from cloudflare user domains with AMP enabled.
Couldn’t this same argument be made that anyone hosting their servers on AWS or any other cloud provider are also suspect? They own the hosts, so they could extract any TLS private keys they want from the guest OS. Or even worse if you are using an ELB and having that terminate your TLS.
Very few companies run their own servers in their own datacenters these days. They trust their vendors, which you have to do. Even then, they most likely use certs granted by a third party, who could easily grant the cert to someone else, too, and allow your traffic to be snooped.
Why do you single out Cloudflare and not those other service providers?
This is every CDN... how is a large, high traffic, website supposed to work without a CDN? There are literally NO large sites that don’t either contract a CDN or build their own (and the number who build their own is pretty small)
> If I was a group who needed to get eyes on TLS traffic without it looking too suspicious, offering free reverse-proxy services would be the way to go
that's a pretty over the top accusation to make without citing evidence
I don't think the poster needed to allege that cloudflare offers free reverse-proxy services for diabolocal ends. The fact remains that they are a vulnerability so perfectly constructed that you couldn't do better intentionally.
Any major intelligence agency that isn't (/hasn't been) investing heavily in infiltrating cloudflare is incompetent.
How is Cloudflare any different from a cloud service provider like AWS, Azure, Google Cloud, Linode, Digital Ocean, etc?
Those are also 3rd party companies who terminate TLS sessions on your behalf and thus have access to your private keys. Seems like they could secretly decrypt and copy your traffic at least as easily as Cloudflare could. Even leased managed hardware requires you to trust the company running the hardware for you.
You have to go all the way to installing and running your own hardware in a locked cage at a data center to even theoretically exclude all 3rd party access to your private TLS keys.
And yes, intelligence agencies would be incompetent if they haven't already implemented methods of penetrating CDN providers, or working on doing so. All of them, not just CloudFlare.
Among other things, it's much harder to get caught in interception on an MITM box. The user never has any kind of real visibility into system. One can also easily force users onto CDN/mitigation services with a simple DOS attack, it's a lot harder to get a target onto particular hosting.
Not really accusing them of anything, but CF is a giant vuln in how you'd expect TLS to work. TLS is supposed to guarantee that data between your browser and the web server is encrypted in transit, but with the CF business model there's a very convenient decryption/re-encryption step right in the middle of that.
Infiltrating CF is far, far easier than any of the other TLS-snooping methods (breaking the encryption, generating a fake cert via bad CA and intercepting, etc); it's not ridiculous to think the bogeyman-du-jour probably has fingers in CF (with their knowlege or not, doesn't really matter), and it'd be irresponsible to assume that TLS traffic going through CF is any more secure plaintext.
If you rely on any third-party for data processing/storage, you're accepting some risk of them being compromised.
If you use CloudFlare/Akamai/Cloudfront/etc. as a CDN, a hacker could view your site's traffic.
If you use G Suite/Microsoft 365/etc. for email or document storage, a hacker could access your corporate documents and communications.
If you use EC2, Azure, or GCE, a hacker could access your storage buckets or dump your VM's RAM.
It all comes down to your threat model. Is your threat model such that you absolutely can't trust any third party with your data? If the answer is "yes" then you should completely self-host and not use a CDN or anything similar. (I.E. an email provider that specializes in providing services to whistleblowers/political dissidents should definitely not use CDNs or public cloud providers.)
But for most businesses it's an acceptable risk, especially since these giant tech companies probably have better security than they do themselves.
For anything but the smallest website, the first server a TLS connection hits is not going to be the end point of the connection. There will be caching, proxying, load balancing, etc, happening, and that will often result in connections that leave the datacenter. There will be decryption and rencryption (hopefully!) happening many times.
I don’t see why CF is any different than these other processes. I am also confused as to why you think CF is so much easier to infiltrate than say, a CA.
Do you think the same about Amazon's ELB (and it's Google/Azure equivalents)? They all are set up by the site owner to sit between user and server and decrypt TLS.
If I was a group who needed to get eyes on TLS traffic without it looking too suspicious, offering free reverse-proxy services would be the way to go (for attack protection and CDN-like features, of course).