Hacker News Reader

Comment by voidmain | Hacker News Reader

It's really not my area of expertise, but it seems to me that today you could use subresource integrity to serve everything static from a CDN without having to trust it a lot.

The real problem is the other stuff they do, like defense against DOS attacks.

View on HN

It's not about subresource protection, it's about them essentially man-in-themiddle-ing each and every connection to your website which defeats - imo - the whole purpose of using HTTPS in the first place. What's the point if it isn't end-to-end?

(disclaimer: my company does this too)

TLS between users and a proxy protects users from lots of different attacks (including the lovely wpa stuff). It's useful, and the alternative is frequently "no TLS at all", not dyi.

Yes end-to-end is better. But you're still going to have to trust infrastructure providers along the way, whether it's at the proxy level or they can just read your disks.

Also I pretty much agree with everything you said about CF ...

You are usually going to have to trust some third parties, i.e. your datacenter provider (though even then, I'm a believer in locked cages etc.). But there's a difference between trusting a named third party and trusting the public internet between CF and your hosting.

"What's the point if it isn't end-to-end?"

Cynical answer: The padlock, the "https://" in the address, etc. A phony sense of "security".

CF's comfort with playing man-in-the-middle should not surprise anyone familiar with the company's origins in examining the content of web traffic. Remember Project Honeypot?

Anyone who wants to attack you will try to intercept/MITM close to you. Unless they have a lot of resources, they will have a hard time finding the datastream between CF servers and origin.

A typical scenario is surfing in public wifi (cafe, airport). Someone could identify a victim and MITM the connection. If the connection is secure to CF, they'll be mostly out of luck.

That is not necessarily the case. You could, for example, get a separate domain and use it for static resources -- put only that on Cloudflare.

It won't be quite as fast, but it'll likely be more than fast enough.

Right, my suggestion was that you would not give them a certificate for your domain example.com, you would just give them a certificate for staticresources.example.com, and you would never load anything from that subdomain without subresource integrity checks (or load anything whose contents or mere existence leaked important information, or...)

Reply on news.ycombinator.com