Hacker News Reader

Comment by SAI_Peregrinus | Hacker News Reader

The one part I disagree with is the section on Cloudflare. I agree that it's better than nothing, but you do have to trust them. I'm not sure that's wise. Not because I expect them to deliberately misuse the access, but because it's an increase in attack surface.

View on HN

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.

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...)

Also their free cert terminates at their servers. If you're in e.g. GCE or AWS, that means part of your trip is unencrypted between their servers and yours, unless you pay for their FullSSL product.

https://puu.sh/y1RUm/03b77351ee.png from https://www.cloudflare.com/ssl/

I’m fairly confident the full SSL option is free.

We looked it up a few months ago and came to the opposite conclusion. Perhaps it's bundled into a larger CloudFlare plan, but on the free tier, I don't think so. I'm having trouble finding pricing for it on their site though, so I may be incorrect! But why even offer the FlexibleSSL option in that case?

I don’t pay for CloudFlare but have access to it: https://imgur.com/a/Zgjfs

The flexible SSL option is just much easier to deploy. It tacks on TLS without any server reconfiguration. Whether or not you want that is another thing, but it certainly has a market.

Hmmm... Well glad I'm mistaken.

Full SSL is free on Cloudflare. It's on all plans and we'll either work with the certificate you have on the origin (e.g. one from a paid CA or Let's Encrypt) or we'll give you one for free (https://blog.cloudflare.com/cloudflare-ca-encryption-origin/)

Literally, no reason to not use that option.

Reply on news.ycombinator.com