> My reservation with Cloudflare is the concept of letting a third party MitM my SSL traffic.

I wonder what the Venn diagram of people who insist every website must use HTTPS for privacy reasons and Cloudflare users looks like.

In my experience, it's extremely rare to find a CDN that doesn't expect to do TLS termination. My understanding of TLS is that it's exceptionally difficult to cache content if you cannot see into the requests.

Perhaps I have overlooked something?

> My understanding of TLS is that it's exceptionally difficult to cache content if you cannot see into the requests.

Not even "exceptionally difficult", but flat-out impossible. From the perspective of an observer, TLS sessions are random data. The protocol is specifically designed to defeat attempts to replay data -- a CDN is indistinguishable from an attacker in that sense.

Right, with Stackpath they do TLS but not necessarily on the primary domain. You don't have to point your nameservers if you don't want to. So you can set them up on a subdomain and use their fake SSL to serve purely static files (if the file doesn't exist on CDN at the time it's requested then their system will pull it directly from your server via a private subdomain, serve it to the client and store it for next time)

So in this way it's possible to setup CDN with shared SSL for purely static files but not the app server itself; you don't have to give the keys to the whole kingdom so to speak and it's cheaper than Cloudflare at the basic level.

Let me see if I follow. Auto-provisioned TLS (misleadingly termed "fake SSL") on the front-end for delivering static contents and caching. A private subdomain with a pinned cert not managed by the CDN to deliver static contents to the CDN. And a third subdomain for the application itself that's not going through the CDN.

I was under the impression that the same result could be achieved with Cloudflare, or indeed nearly any CDN. Was I mistaken? Though you may not actually need a secret, private subdomain for static files with all CDNs.

Again, please let me know if I've made a mistake somewhere. I'd love to learn something this morning.

You're right about that. So it might look like this

static.domain.com (CDN subdomain with auto provisioned TLS)

static-uncached.domain.com (private pass-through subdomain when CDN is missing a file)

www.domain.com (app server hosted wherever)

You're right that you could do something similar with other CDNs including Cloudflare (you can just set the www subdomain to "bypass Cloudflare" to accomplish a similar result), but I'm not aware of any way to use Cloudflare on a domain without forwarding your nameservers to them, effectively giving them complete control over the domain. At least with Stackpath I can host DNS wherever and simply point the subdomains I want at them.

Also, by the time you do the work to split static files into separate subdomains you might as well go with a dedicated CDN. One of the selling points of Cloudflare is for sites serving everything on one subdomain that they can forward to Cloudflare and get caching without any work.

They have a CNAME setup where authoritative DNS stays outside of Cloudflare: https://support.cloudflare.com/hc/en-us/articles/36002061511...

It requires at least the Business level plan, though.

Ah my bad. That’s probably why I never knew about it. The $200/month entry price is steep there.

Hundreds of dollars a month doesn't seem material for a company.

Nope, but I'm sure lots of companies are in this situation, where they just barely need the features of the lowest paid plans, end up scaling across several domains and Cloudflare makes a ton of money off a vast majority of customers that will never need their more advanced features.

Plus that means hundreds of unique domains with unique content. If you have hundreds of domains all pointed back to one site with a single forwarding rule, 99/100 could be free tier accounts.

Unless you're sending all your traffic back to physical machines that you own locked into a cage in a datacenter, you are probably letting someone MITM your SSL traffic. For example if you are hosting on AWS, Amazon has access to your keys. If you are hosting on a hardware server leased from Hetzner, Hetzner has access to your keys.

When a 3rd party has access to your keys, their responsibilities to you are spelled out in your contract with them. That's true for CDNs as well as hosting companies.

There’s a difference between a VM host with the technical ability to carry out a targeted MITM attack against its customers using hardware-level access, and a provider that sells MITM as a service.

It's more complicated.

For most websites today if someone can intercept traffic somewhere close to the server they don't even need the keys, they can just fake responses to pass CA validation and issue valid certificates with their own keys and MITM like there is no encryption.

And coldboot attacks performed by a hosting provider staff of dumping memory and finding keys isn't that realistic of a threat, just like putting servers into a locked cage on someone else's property isn't much of a protection.

I send traffic for my sites and apps to physical machines that I own and operate in a secure location, but I doubt most people are doing this.

You don't need to use your SSL certificate for the CDN. Most websites that use CDNs only do so for static assets such as images, fonts, CSS, etc... the dynamic content comes from the origin server, encrypted with a private key that is not handed out.

If you press F12 in your browser and navigate to some major sites, you'll notice anywhere between 1-5 different CDN domain names that aren't directly related to the original host in any way.