Cloudflare powered censorship in Pakistan works in a similar fashion. ISPs block websites, but because Cloudflare's data center forwards using local ISPs, you get a nice secure blocked page.
A public letter to CloudFlare to fix their snoopy vendor
41–50 of 117 posts
Re: A public letter to CloudFlare to fix their snoopy vendor
#42Earlier quoted context omitted.
It fixes the issue, and that has been the recommended fix I've been offering developers all this while.
So really website owners are just misusing Cloudflare? How is this Cloudflare's fault?
In this case, it is not a random party in the CloudFlare--GitHub connection (say a network operator in UK).
The snooping intermediary (Airtel) in this scenario is one that has a commercial relationship with CloudFlare and powers CloudFlare's network.
CloudFlare has been aware of this issue for years, but it hasn't done anything to get its vendor to fix their network.
Re: A public letter to CloudFlare to fix their snoopy vendor
#43Earlier quoted context omitted.
It fixes the issue, and that has been the recommended fix I've been offering developers all this while.
So really website owners are just misusing Cloudflare? How is this Cloudflare's fault?
2 of the 4 SSL options Cloudflare provides will give a nice lock icon in your address bar and HTTPS will all look like it's working fine, but the connection to the origin is still insecure. It's very misleading and IMO irresponsible of Cloudflare to offer these options.
Re: A public letter to CloudFlare to fix their snoopy vendor
#44What if the site owners change their SSL settings to Full SSL though?
Full isn't actually enough to secure this - with their MITM position, Airtel could send an untrusted certificate and continue to intercept and modify traffic. Full (Strict) is the only safe option.
Re: A public letter to CloudFlare to fix their snoopy vendor
#45Earlier quoted context omitted.
It fixes the issue, and that has been the recommended fix I've been offering developers all this while.
So really website owners are just misusing Cloudflare? How is this Cloudflare's fault?
Well, they're sending packets to an upstream ISP that then does the wrong thing with them. They certainly have more leverage to get that upstream ISP to clean up its act than their customers do.
More broadly, if enabling a particular Cloudflare feature (in this case, Flexible SSL) constitutes "misusing Cloudflare", then Cloudflare should simply not offer that feature at all. There's a bit of a balance here; when they introduced it in 2011, a lot of hosts didn't offer HTTPS at all and none of them offered it for free. MITM is genuinely more likely to happen between the end user and Cloudflare than between Cloudflare and the origin server (because the former can involve things like unsecured coffee-shop wifi), so for webmasters who couldn't use end-to-end HTTPS, it provided a real security benefit—which had to be weighed against the cost of telling end users that their connection to the site is secure against interception, when that wasn't entirely true.
I think there's a case to be made that this tradeoff was worth it in 2011 but is not worth it in 2022; today, end-to-end HTTPS can be had for free, and is easy enough that there's usually no excuse not to.
Re: A public letter to CloudFlare to fix their snoopy vendor
#46Re: A public letter to CloudFlare to fix their snoopy vendor
#47Earlier quoted context omitted.
It's a little hard for me to believe that there are IPv6-only users out there. Who are these people? edit: I realize there are plenty users behind NAT64 gateways etc, that's the point: how many users out there have no IPv4 connectivity at all?
> It's a little hard for me to believe that there are IPv6-only users out there Why is this hard to believe? IPv4 ran out a while ago depending on which part of the world you are in. New networks do no longer get IPv4 by default. Some can get very small allocations that are barely enough to operate nat64 gateways for a few thousand users. Quite a few networks decided to not invest in legacy IP any more and better spe…
IPv6 without any transition mechanism is not Internet access. It's more like a tenth of the Internet. If an ISP has to buy a few addresses to run NAT64 that's a cost of doing business.
Re: A public letter to CloudFlare to fix their snoopy vendor
#48Glad to see this getting attention. Flexible SSL is an awful option that has no place in the modern encrypted web. Out of the four SSL options Cloudflare gives users, only one is actually secure. It's a huge foot-gun.
I assume you mean only ` Full (strict)` is secure, and not even `Full`? I happened to be recently looking at putting cloudflare in front of an S3 bucket, and it looked maybe easier/more feasible to do with `Full` instead of `Full (Strict)` -- because you can skip configuring the S3 bucket have an SSL cert for your actual front-facing domain (which can be cumbersome and/or more expensive to set up) and just let CloudF…
Just use a free Cloudflare Origin CA certificate and set to strict. Encryption for the whole round trip unless someone accesses origin server directly.
https://developers.cloudflare.com/ssl/origin-configuration/o...
Re: A public letter to CloudFlare to fix their snoopy vendor
#49Re: A public letter to CloudFlare to fix their snoopy vendor
#50Earlier quoted context omitted.
Disagree. TLS terminated at the edge, by a trusted partner, is perfectly valid and in many cases a great plus. You should, however, then always have a tls connection back to the main host, this is obviously not always the case and is wrong. Ideally CloudFlare would not make it possible. By terminating at the edge it enables many useful features of services such as CloudFlare that would otherwise not be possible such…
TLS termination in the sense that you terminate TLS and then send the traffic to the origins without encryption. Cloudflare services basically works at layer 7 so they must decrypt all the traffic.
Ah, your original comment was not clear, we agree then.
I'm just frustrated by the bandwagoning criticism of any use of CloudFlare and the suggestion anyone using them is MITM their own visitors, when clearly they are just another part of your own infrastructure (when used correctly). Your comment "TLS termination on the edge services is just stupid" made me think you were doing that.