5 ms·

An alternative: <meta http-equiv="Content-Security-Policy" content="script-src 'self' https://only-scripts-allowed-from-here.com https://only-scripts-allowed-fr

by okzgn 1mo ago

An alternative: <meta http-equiv="Content-Security-Policy" content="script-src 'self' https://only-scripts-allowed-from-here.com 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 https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

pcmaffey 1mo ago
Also can add "Cache-Control: no-transform" header, which prevents modifying the payload.
- hahn-kev 1mo ago
  Does it prevent it? Or just request it? There's no way to enforce that is there?
  - chrisweekly 1mo ago
    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.
1vuio0pswjnm7 1mo ago
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.
- okzgn 1mo ago
  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).
- 1vuio0pswjnm7 1mo ago
  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
  - zmgsabst 1mo ago
    This is a tangent, but your setup sounds interesting to me — would you share more about how to configure such for myself?
    - 1vuio0pswjnm7 1mo ago
      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
robin_reala 1mo ago
script-src 'none' is a more secure solution.

by okzgn 1mo ago

pcmaffey 1mo ago

Also can add "Cache-Control: no-transform" header, which prevents modifying the payload.

hahn-kev 1mo ago
Does it prevent it? Or just request it? There's no way to enforce that is there?
- chrisweekly 1mo ago
  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.

1vuio0pswjnm7 1mo ago

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.

okzgn 1mo ago
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).
1vuio0pswjnm7 1mo ago
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
- zmgsabst 1mo ago
  This is a tangent, but your setup sounds interesting to me — would you share more about how to configure such for myself?
  - 1vuio0pswjnm7 1mo ago
    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

robin_reala 1mo ago

script-src 'none' is a more secure solution.