An alternative: <meta http-equiv="Content-Security-Policy" content="script-src 'self' https://only-scripts-allowed-from-here.com">
This makes the client only load self-hosted scripts, or scripts only from the specified origins, among the other directives CSP allows (e.g. restricting styles, images, frames, etc.): https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
If Cloudflare (CF) has r/w access to the response body, which CF does have by default, then CF can easily modify or remove that <meta> tag. The risk is not abated
The risk of third parties injecting scripts, etc., e.g., analytics, advertising, etc., into response bodies (web pages) is usually cited as a rationale for using HTTPS^1
CF somehow avoids the usual objections. CF is a MiTM but few people object
1. For example, a data collection, surveillance and advertising services company that operates a www search engine and releases a web browser may not want an ISP to inject scripts, etc., e.g., analytics, ads, etc., into web pages as it might compete with the company's business. As a defense against such ISPs and other third parties that are potential competitors for data collection/surveillance/advertising services, it might favor HTTPS sites in its www search engine results, promote HTTPS at conferences discussing its web browser, etc.
FWIW, I operate own DNS (including own custom root.zone) and I MiTM own TLS traffic with a localhost forward proxy. With this setup I get r/w access to response bodies, I add a CSP as an HTTP response header, and a long list of other traffic manipulation. There is no tracking, ads, telemetry, etc. Nothing leaves the computer unless I allow it. Operating DNS plus forward proxy gives me lots of control
Letting Cloudflare (CF) operate DNS and direct traffic through its proxies gives CF control
It's interesting to see how they use it under market pressures
This is a tangent, but your setup sounds interesting to me — would you share more about how to configure such for myself?
Many years ago I started to describe how it works in an HN comment and some reply complained about the idea of terminating TLS, i.e., decrypting, and then re-encrypting. Obviously this sacrifices something, e.g, speed, in order to gain _control_
But this is what Cloudflare does and no one seems to mind
Large companies also do this to protect their LANs
I'm not running a CDN, only a small home LAN. I'm only procesing a small amount of traffic on a personal computer. This setup is fast enough for me, it's not slow at all
The basic configuration is generally:
1. Configure DNS to point to the local proxy listening address #1, a local address, e.g., using a wildcard in a zone file
2. Configure the proxy to terminate TLS, "do stuff", and then forward to proxy UNIX socket path #2 or proxy listening address #2
3. After doing the stuff, the proxy then sends the traffic over the internet
The "do stuff" part is personal. It depends on what one wants to do. There are seemingly endless possibilities
It's not likely the constantly changing configurations I use would be suitable for others. It's all based on personal preferences and usage habits
I rarely use a graphical browser, for example
I don't make piecemeal remote DNS queries like most www users. (IME, most A RR's stay the same over long periods.) I get bulk DNS data periodicallly from a variety of sources and load it into the proxy's memory. When I make an HTTP request there is either no DNS lookup because I'm using the IP address of the proxy or there is a single, local DNS lookup which returns the address of the proxy. There is no access to remote DNS
When I first decided to start inspecting own TLS traffic by terminating and re-encrypting, I initially tested the idea using socat
After I saw that it worked, I started using other software like haproxy
I never expected this approach would work well enough but many years have gone by and I'm still using it. The configurations I use are much longer and more complicated than any sample I have ever seen on the www
It's funny that Cloudflare is decrypting and re-encryting _other peoples'_ traffic, and this is thought to be AOK, but aside from large companies few people seem interested in doing this with their _own_ traffic on their _own_ computers on their _own_ networks
It can be useful, IMHO
NB. I actually do not encrypt then re-encrypt for the majority of HTTP requests I make
I generate HTTP myself using own programs and connect to the localhost proxy using various TCP clients. The proxy does the encryption and remote connections not the client programs
I process response bodies, using own software, into SQL, CSV, simple HTML or plain text
This design isn't for everybody, but it's what I strongly prefer
In the way I use it, for the majority of HTTP traffic, no speed is sacrificed
There are a variety of proxies that can be used to forward traffic. I use only a small selection, haproxy is the largest, tinyproxy is the smallest. Personal preference will vary
The local DNS setup is just habit. I have been using djbdns and a custom root.zone for a very long time, before "privacy" was the issue it is today, and I have own particular prefences; every user is different. Using a firewall to send traffic to the proxy is an alternative. The motivation for me was always experimentation, learning and control, not "privacy"
"Privacy" is something one could aim for, if one has _control_. But IMHO without control, "privacy" is nothing more than marketing
This sounds like exactly the kind of thing I'd waste a weekend setting up but what do you actually do with the decrypted traffic? What do you inject? I know you said it's personal but maybe some basic ideas.
Do you find any websites or services that fail because of cert pinning or similar? Why do you restrict dns caching to periodic intervals, just for external privacy?
In terms of the speed I doubt the time to decrypt and encrypt tls is noticeable in modern times, especially given how slow websites have become. It's not like a load balanced website behind cloudflare isn't already doing this 3 times
Just out of curiosity, which proxy do you use?
How much speed are you actually sacrificing? I'd assume modern hardware can decrypt/encrypt TLS very fast.
Side note: I remember working for a company in early 2000's that had Sparc III 1U servers we had to buy crypto accelerators to do this until I had to convince them to use dell/linux.
Thanks for the background context, very interesting and realistic. Yes, of course it also has read/write access, though I always make sure there’s no interference of that kind. It has only happened to me once, where a binary I hosted on Pages didn't work when downloaded with wget (though that happened several years ago).
Also can add "Cache-Control: no-transform" header, which prevents modifying the payload.
Does it prevent it? Or just request it? There's no way to enforce that is there?
CF owns it all, coming and going (request handling and response writing), thus can choose how/whether to interpret, ignore, modify or append any headers.
script-src 'none' is a more secure solution.