Hacker News Reader

Comment by tptacek | Hacker News Reader

Protection against "passive attacks" is mostly meaningless: if you can observe packets, you can hijack sessions. It's only the certificate validation that Cloudflare apparently performs only in "strict" mode that prevents this attack.

In particular, the "full" TLS they offer that Hunt is taking advantage of (because he can't deploy a working certificate) is grievously insecure: he's essentially running his system on top of the equivalent of the "goto fail" vulnerability in Safari that the Internet was (justifiably) freaking out about two years ago.

Hunt is smart about a whole lot of things, but he's wrong about this. There's nothing "unhealthy" about the absolutism here: you either have end-to-end cryptographic security, or you're vulnerable.

View on HN

It's easy to use our Strict mode. We'll give you a certificate for the origin for free: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/

Or you can bring your own certificate from someone like Let's Encrypt.

If it's that easy, why even have "strict" mode? Why not make the branding less misleading, and rename "Full" to "Weak"?

I'll bring that to the PM responsible.

What's the likelihood of actually seeing a change?

PM here—he's already brought to me to discuss :)

And is tree cert pinning for self-sign veers? If not, why not?

Can you please also include an HTTP response header that tells us the level of verification of the connection to the origin?

If CloudFlare wants to live dangerously with origin connections, fine... but give end users a way to drop the connection if it isn't secure, like our browsers would normally.

By the time you've gotten this response header, the request has already been sent over the connection that you don't trust, and at least part of the response.

But at least you can cease further communications. Feel free to suggest a better idea.

I love your suggestion, with the caveat that browsers send a pre-flight interrogation request (similar to OPTIONS with CORS) to determine if the origin connection is secure before sending a legitimate request (containing potentially sensitive data).

Reminds me of the whole USB 2.0 Full Speed vs USB 2.0 High Speed nonsense from the early 2000s. Raise your hand if you can tell me which one is 480 Mbit/s and which one is 12 Mbit/s without looking it up online.

Full Speed has existed since USB 1.0 — it’s “full” relative to USB 1.0, where the only other option was Low Speed — but I agree that the name was a poor choice.

Rename "Full" to "Weak", and apologize for the crime that was "Flexible"!

You should really reach out to Andy Ellis. Akamai forces cert pinning when HTTPSing back to customer origins for some very good reasons that he can explain to you.

> There's nothing "unhealthy" about the absolutism here: you either have end-to-end cryptographic security, or you're vulnerable.

I'm not sure why he talks about absolutism, where this usage basically invalidates the whole point of TLS. This seems like an after-rationalization on why he chose to use CloudFlare, there is much more reasons not to use them. In the end of course it depend on what type of site you use it for.

While in most cases - Cloudflare is better then no Cloudlfare as discussed in the article. It seem however it's nontrivial for a user to determine whether or not a site is hosted on Cloudflare, because there is certain threats that it can't protect against. If people had a browser plugin to alert if the vendor is capable of doing such MITM, then it would be up to the user if they want to recieve content where it's capable of not being sent end-to-end. Sadly it's a bit hard to make that judgement call, since all CDN's do very similar things.

The only way to make this "less bad" would be if there was a way to determine if the backend infrastructure was in fact loaded end-to-end via TLS. Perhaps some non-cachable content? Not sure what the right answer is here.

"it's nontrivial for a user to determine whether or not a site is hosted on Cloudflare"

It's easy to detect when Cloudflare is being used. There are multiple ways.

Is there a Chrome or Firefox plugin that can detect non-"Full (strict)" and alert me?

You could try Wappalyzer. Your comment just reminded me of that gem. No security state detection though. May be added if CloudFlare adds an x-cloudflare-crypto header.

https://wappalyzer.com/applications

That might actually be what we're looking for, we assume that cloudflare is already trustworthy since they're performing the MITM - however there is no way for the client to distinguish whether the backend network is in the clear or not without such an indicator. Also this assumes we're OK with Cloudflare to report the backend status accurately and that can't be spoofed as well.

Just use the net via a VPN when out and about. You'll rapidly find out who's running CF, and how incredibly annoying their constant captchas become. (Approx 25% of the time CF decide my VPN provider (PIA) needs captchas. This lasts a couple of days, then rest of week clear. Repeat)

They're positively surfer hostile.

I'm actually planning on renting a VPS soon to use as a personal VPN, dedicated IP, hopefully dedicated bandwidth etc.

I don't have even the smallest idea how to configure one or what software I actually need, BUT, my greatest fear is that I'll end up with a pretty "broken internet" since I won't be using a residential IP anymore.

Cloudflare will just think that I broke into some random wordpress site and started using the server to ddos (who? with 1-2 requests/minute?).

It doesn't look that they implement any kind of serious IP reputation algorithm. I have a static residential address since I remember signing the contract, almost a decade ago, pretty paranoid about security with a clean PC and I never seem to stop getting captchas.

Is PIA a paid only service? I doubt any "hackers" will be using it to break cloudflare sites. On the contrary, I'd argue its users are actually more civilized than the residential folks.

Not sure I'd want a VPN via a VPS, as you'd lose the anonymity of being just one of a swarm using a particular IP point of presence. Though you'd probably get fewer CF captchas, but all traffic would be you.

I've no idea how clever CF are (tempted to quip clearly not clever enough) to decide their sites or their network is under attack. I'd imagine there's going to be a lot of connections from PIA's users, from all the various regional exits. Same for all the other VPN companies. I can't believe they can't be distinguished from a real DDOS or whatever else they see as "bad traffic".

Where Cloudflare start winding me up is they treat each domain alone. I get a captcha on blog a, 30 seconds later I'll get another at company b, 5s another at blog c. If CF gave me a 3 or 24 hour cookie I'd hate them so much less! (There's a couple of ways around captcha madness - If I switch to another exit I can usually get a captcha free one)

PIA is paid, but good value - around $35 a year.

He even has a working certificate---just for a different name.

It sounds like Hunt expects to not see much interception and manipulation at the "backbone." My own experience suggests that such is common at national borders, and becoming common at more and more ISP borders.

The question is what fraction of attackers that can't force cloudflare to pass them their data is capable of attacking server <-> cloudflare versus cloudflare <-> client.

Hunt seems to posit that the above ratio is small, I take it you disagree?

On a side note, I don't get why cloudflare doesn't let you pin a public key through their interface; that would remove the need for CA signing. Considering you have exactly one client (cloudflare) connecting to your server, it's not like key distribution is hard. Of course this is moot now that cloudflare offers you signed certificates for free, but would have been a simple solution.

"Small"? What does that mean? Cloudflare doesn't have special private backhaul networks to origin servers; they use the public Internet like everyone else.

In this context I think it means "unlikely to be a free public wifi access point"

it kind of sucks that cloudflare can't check the servername for the certificate he wants to use. i haven't used cloudflare but I assume there are three ways it might be checking the cert at the backend:

1) using the real hostname of the website

2) using the hostname of the backend website - assuming you supply a url with a hostname to cloudflare. however, this hostname in the backend url is used in the Host header which ends up causing lots of problems.

3) using the hostname of the backend website - but the hostname of the real site is used in the Host header.

4) explicitly let you choose the servername you want to verify

imo. it would be nice if cloudflare gave you the option between 1) and 3) or 4).

EDIT: oh. just noticed the cloudflare reply with the link to: https://blog.cloudflare.com/cloudflare-ca-encryption-origin/

It shouldn't rely on server name, but on the actual key or signature. Actually, I believe many of hosts running behind the CloudFlare wouldn't want to expose any meaningful server names, so the actual server location would be harder to spot.

I.e. you generate your keypair and produce a self-signed certificate, you should be able to give your public key and the actual key would be used for authentication. The subject (and SANs) of the certificate are ignored so it could be like "/CN=localhost" - only the key material is what matters here. That would be secure - in a sense third-party attacker won't be able to sniff what's between you and CloudFlare.

(Or you could generate your own (self-signed) CA, generate a certificate signed by this CA of yours, and give CloudFlare your CA's public key. This makes sense if you have multiple hosts and you don't want to share the same key.)

Their business model has always been MITM, sniffing and modifying content. They do not just blindly pass traffic. Cloudflare and end-to-end encryption are incompatible. They need access to the traffic. What is troubling is how easily they can fool customers or end users into believing that they are offering satisfactory encryption when in truth they are not.

Stepping on to soapbox... TLS needs to be replaced with something simpler, with fewer "buttons, dials and knobs". TLS pontificators need to separate authentication from encryption. They are two different problems, and it's possible we may only have a satisfactory solution for one of them. If that's the case, and it's the former problem that remains unsolved, then it could be worthwhile to reconsider the relative value of encrypted "channels" versus per packet encryption.

Reply on news.ycombinator.com