Hacker News new | ask | show | jobs
by bsamuels 2657 days ago
> 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

4 comments

> that's a pretty over the top accusation

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.

In this regard, don't compare them to AWS, Azure, Google Cloud, etc....

Cloudflare is a CDN, so compare them to Fastly, Akamai, and all the various other CDNs listed at https://en.wikipedia.org/wiki/Content_delivery_network

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.

Why would penetrating a CDN company be worse than penetrating a cloud hosting provider, when it comes to decrypting TLS traffic?
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.
It's not an accusation leveled at CF--it's a consideration of possible effective strategy in general.
Where is the accusation?