Yes, on both macOS and Windows 11. On Mac you have to create/use a simple .mobileconfig profile. On Windows you have to separately provide both IPv4 and IPv6 addresses.
Interesting. UK ISPs have had a similar block/filter list for many years (mostly covering copyright-infringing torrent websites and the like). But it’s more robust than a simple DNS block. A VPN can bypass the block, but changing DNS providers will not.
The ISP's blackhole the IP for some blocked domains. So changing your DNS to 8.8.8.8 will resolve the domain, but the IP won't work. A VPN avoids this, since the traffic goes via the VPN IP.
I remember hearing someone complain on HN of their site getting blocked because it shared an IP with an illegal soccer livestream. I can’t imagine they’re doing this to IP blocks owned by CDNs like Fastly, CloudFlare, or CloudFront though. Or are they? Does this regularly break most of the internet for UK customers?
TBH it is not ALL cloudFlare IPs but a significant quantity of sites using and not using CF CDNs. You cannot imagine what a pest that is even for legit users of legit collateral damage pages. CloudFlare is in the courts appealing/countering initial court allowance to blockade and ISPs are bound to comply to blackout requests. You can look at https://hayahora.futbol (traslation: is there soccer match now?) to see affected domains.
While I am not some reputable source per-se, I have some tailscale presence over there and can corroborate my exit nodes find cloudflare sites blanket blocked on weekends.
Cloudflare works with the UK government to facilitate blocks within their infra, I assume in exchange for being allowed to access UK network infrastructure.
In the case that a blocked site resolved to a Cloudflare IP, it would likely be kicked off of Cloudflare, or geo-blocked for UK users (by Cloudflare).
Ironically that url is forbidden for me, I was under the impression that CF were fairly anti censorship, or at least they inferred that they should not be the one calling the shots (in reference to kiwifarms)
If this is the case, someone running their own recursive DNS server (like Bind9 or Unbound) can trivially bypass these restrictions. Doing this is a sensible step towards more privacy, regardless of censorship.
Maybe this is a good place to ask: what is the easiest way to use my own DNS entirely in user mode (not a server when I can't change which DNS is pointed to, since not an admin), a SOCKSv5 proxy?
It looks like this is possible with Chrome-based browsers using a command line flag (--host-resolver-rules) or in Firefox settings. Is there a better way?
Not OP but I also use ControlD. I admittedly like NextDNS interface better, but honestly, I rarely need to login anyways.
So why ControlD? Because I don't want to run my own piHole, basically. They maintain ad block lists that you can edit as you see fit to add things or relax things that may cause issues(which you can't do easily with public ad blocking dns servers).
Why ControlD then and not NextDNS? First, because their support was awesome when I had an issue. AFAICT it was the founder actually emailing me back and forth, and it ended up being my ISP's fault, but I only knew that based on research provided to me by support. Secondly, I got a good deal on a 5-year subscription at one point.
Happy to answer any questions, not affiliated but a fan of the service.
Not GP, but I just run my own dns inside the network (unbound on a little openbsd sbc) with a cronjob that pipes oisd.nl into it every night, works great..
Just enabling ECH doesn't stop this, firewalls can see it and mangle the data to force a downgrade because most servers need to support older protocols. It's more accurate to say that once sites only support ECH, then they'll be forced to stop downgrading or deal with angry users.
In the wild, that's not true at all[0][1]. The corporate firewall at my employer actually wasn't able to block ECH until they updated it then it was able to block sites as usual.
This is literally impossible. What your corp fw likely does is mitm outer SNI because your IT department installed your company CA in every client's trust store. So unless you do that at national level your only other option is to block ECH entirely.
Edit: actually totally possible but you need build quantum computer with sufficient cubits first =)
The DNS filter setting on the FortiGate analyzes the DoH traffic and strips out the ECH parameters sent by the DNS server in the DoH response. If the client does not receive those parameters, it cannot encrypt the inner SNI, so it will send it in clear text.
So basically they mess with DoH ECH config and trigger fallback behavior in the clients. I don't think any browsers do this yet but I think this loophole is not gonna last.
I'm surprised that works. Doesn't TLS1.3 do the thing where it crosschecks (a hash of) the setup parameters after key-agreement to protect against exactly this kind of downgrade attack?
(My phone screen is too small to look through the RFCs right now.)
I think what you're describing is TLS1.3 Finished verification so that happens after DoH response during the actual handshake. Basically this works because ECH is fairly new and there's no HSTS-style "always use ECH for this site" configuration yet. And ofc this only works if you configured FortiGate as your DNS (corp network) or if it's doing MITM (though I'd expect browser would verify cert fingerprint for DoH connections as well).
