@mafe @thc Yeah it's called #encryption.
It also completely defeats the point of a CDN/caching-proxy like Cloudflare.
There are a few issues at play here, but mostly the redundancy limiting ability for DDoS could be handled by #p2p content-addressed mirrors, the problem is that on the #clearnet that has major #privacy issues.
So instead of doing the smart thing and deprecating the clearnet for application-level traffic, people just went "fuck it" and took the shit (but easy/simple) option.
@thc I remember ISPs doing this kind of MITM attack. I did not realize that was possible given https.
Mostly I’m puzzled that it hasn’t gotten more attention.
It surprises people that CF can see (and modify) the plain HTML even under https, but if you think about it, any CDN has to do that to be able to cache content.
Same as with a VPN, using a CDN requires some amount of trust. Unfortunately, it only requires trust from one side (the backend service) and not the other (the end user), which doesn't have any say in the outcome.
Do you mean to serve the HTML and any response from the front-end directly to the user and only let the CDN cache images, CSS and scripts? Yes, you can do that, even in the current offering of CDNs.
It does reduce the ability of the CDN to spy you, at the cost of a more complex setup.
Still the choice of the backend service provider, not the end user.
@PeoriaBummer @lispi314 @thc @tychotithonus they still gotta answer subpoenas and their employees aren't immune to the three letter agencies.
Same goes for every us based company, but most don't serve that much of web traffic.
@guigsy When people use CDNs, they ususally don't encrypt their shit and trust a third party, the CDN itself, to do TLS encryption. Even if servers handle TLS, it's a separate connection anyway
Users never directly sent requests to the actual servers they want content from. They send requests to CDN servers, which request the content from, which then requests it from the "end" servers. CDNs are MITM-by-design.
Client <=Encrypted or plaintext=> CDN <=Separate connection=> Service servers
@thc The image in the parent post is a screenshot of the first paragraph of the “Parsing and modifying HTML on the fly” section of this Cloudflare blog post.
I don’t like seeing people take my side for reasons I disagree with, so:
On-the-fly HTML rewrites are standard features for any website hosting provider, esp. classic PHP-enabled web hosts. The “HTTPS-compromising intermediary” argument” doesn’t hold water if you treat a CDN as a hosting provider.
There are much better reasons to oppose CloudFlare: their “hate credits”, scope creep, and undermining of browser diversity (by sending uncommon TLS fingerprints through CAPTCHA hell) are better reasons, especially given their market share.
Last Friday, Tavis Ormandy from Google’s Project Zero contacted Cloudflare to report a security problem with our edge servers. He was seeing corrupted web pages being returned by some HTTP requests run through Cloudflare.
, commonly cited figure last year was 20%) being visible gives clownflare a lot of power to abuse. The line between a backup key for a friend and a master key that can unlock every door in the neighborhood is not so fine IMHO.> safely rewrite http:// to https://
What for? Properly manitained websites should use https:// by default, all the time one handle it on the webs servers instead of trusting some third party… It's not Jed to do HTTPS
Al the rest is bad and instrusive (injecting google spyware, amp bullshit¹ which another google's spayware, modifying HTML…). Only idiots with 0 respect for their users (e.g marketing people) would want such intrusive crap
1. Useless extra JS won't make pages "load faster"