Hacker News Reader

Comment by voidmain | Hacker News Reader

Yeah, it's only been 6 months since https://en.wikipedia.org/wiki/Cloudbleed. I guess we have to hope that they got religion after that :-/

It's kind of funny that we have Google pushing to force everything to be HTTPS, and in response everyone adopting a service provider that MITMs them through shared proxies written in a memory unsafe language, and doesn't require a certificate or even HTTPS from the origin site (so that third parties can still do MITM attacks), etc.

It's still an improvement over an `http` scheme site in an absolute sense -- at least it protects customers from their own ISP or unencrypted wifi -- but it also hides the insecurity from the user. Oh, well.

Maybe what we really need is strict liability for data breaches. A few companies getting successfully sued for $100 per user account after a breach would actually start to change the culture around security.

View on HN

I see CF as a step backwards at this point. I'm sure they have learned their lesson but their response was absolutely terrible and that makes me wonder about their leadership. As long as that doesn't change there is a good chance that there will be a repeat at some point and so I'm not comfortable with placing that much trust in them.

Fortunately I don't need them, if you are in a position where a CDN is a must then that is a decision you're going to have to live with (or find another one than CF).

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.

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