1. IIUC, when SNI is encrypted (in TLS 1.3?) almost everything is out the window.
2. Local devices can do DNS over HTTPS (DoH) and DNS over QUIC (DoQ) to look up their stuff, so DNS-based blocking will soon be obsolete.
3. The browser itself is controlled by the biggest ad-vendor around (Google), so you’ll probably get no help there.
The only solutions are:
A. Use browsers not controlled by Google (i.e. not any Chrome fork either).
B. Use only apps and devices locally which do not display ads. (This is, in a way, a generalization of A.)
C. Legislate away the business models of ads and the media and “smart” devices which use ads.
(A very similar argument can be made for user tracking and telemetry.)
There's no reason to let applications on your device bypass your own network settings - and this is something we probably need to start accommodating in Linux distros to start with (specifically: disabling all the weaponized E2E encryption that vendors are using, and forcibly MITM'ing it with keys under the users control).
Network-namespaces should make this eminently possible - launch the user's entire environment into a network namespace which can only speak to "user rights" networking stack.
https://kb.adguard.com/en/general/how-malware-protection-wor...
Or perhaps forget about VMs, and have some kind of browser plugin that performs "fake browsing" - to throw off analytics - with your real cookies, but hidden from view, so it's not annoying to the live user browsing the web in the usual manner.
Privoxy, dansguardian, Squid (AFAIR), and others.
The notion that SSL/TLS means that ONLY the webserver origin and web browser client are permitted to see or mitigate content ... is itself harmful. Trusted proxies under your control do have a place, though yes, that introduces new points of contention as well.
That’s the evil genius of doh- you can’t block 443 and their “dns server” could be the same hostname as the site you visit … and now we’re discussing mitm’ing ourselves…
Sigh.
Edit: I should have read the About section more carefully:
> Privaxy is also way more capable than DNS-based blockers as it is able to operate directly on URLs and to inject resources into web pages.
Makes sense. So it potentially has the fine-grained control of a browser-based blocker but also has good performance like a pihole. Sounds compelling. Now I’m interested to know why it’s not been done this way before? Is it just a hard problem to solve, and no one has attempted it yet?
Most commercial firewalls for the last decade plus have such features.
I don't know the reason why the devs of this project think they need to start afresh, there are already tools like Firefox+unlock origin+ pihole which should solve most if not all of the problems. Why not incorporate the defining feature into pihole so that people don't have to add more complexity?
Do I switch off my pihole and set this up?
What harm does it do? Sure, some combination of 3 or more other things might give you most of the same functionally but why shouldn't people have the option to chose whichever works best for them? Even if the capabilities were 100% identical it's still worth it because it gives you an option if the thing you're using goes evil or stops updating or turns out to contain a vulnerability that takes months to fix etc.
Even better, it could lead to innovation. Maybe Privaxy does something better than pihole does, or has some nice feature they don't and pihole sees it, loves the idea, and makes that improvement or adds that feature too and suddenly everybody is better off. Maybe just having competition helps improve things.
I'm really struggling to understand how anyone loses here, or why it's preferable to have our options limited.
Cert pinning defeats this on 99% of consumer devices and introduces a security hole in the browser by subverting the trust model. Unless the proxy is doing 100% of the same thing the browser is doing, and it isn’t, you are weakening browser security too.
Instrument the endpoint (browser plug-in) or control name resolution (filtering DNS server that uses DoH to prevent upstream filtering).
Keep in mind that ad-blocking browser plugins aren't exactly secure either. They have access, not only to every network request, but every keystroke, mouse wiggle, etc. And all it takes to all fall down is for whoever is maintaining it to cash out and sell to a bad actor: you'll helpfully be automatically updated to the new, state-owned version.
The FAQ doesn't seem to discuss the issue at all, which is not a good sign:
If I set NextDNS with DoT in my Android under the "private DNS" setting, and turn on the NextDNS setting with DNS rebinding protection, would the phone and some apps still find a way around it?
I also use NetGuard, but it's more cumbersome and doesn't allow DoT.
Chromium contains its own DNS resolver so connects directly to a DNS server rather than use the OS, but it would normally default to your OS settings (and only use DoH when they find a matching entry in their list of DoH providers).
Desktop Firefox is an example of an app that defaults to DoH from 1.1.1.1 (in some places).
I'm not sure I understand why it would be more capable than a DNS blocker ?
If it's just because you can inject into the traffic that's comparing apples and oranges ? Or am I missing something ?
A DNS based blocker will not be able to block it, but an extension or a proxy based blocker that looks at the HTML content will be able to block it.
So yeah, inject as well as as modify the HTML directly.
It could do things like shimming advertising libraries as well defanging them potentially.
So yes, the reason is exactly as stated in the quote. It is more capable because it can operate on URLs and on the resources of the website directly.
"The service may not tolerate TLS interception."
I figured the proxy would be making the request entirely independently. How would an external entity even know the data was later being passed on?
This remote interception then involves turning a CONNECT back into the classic proxy connection. First a TLS session from your client to the proxy, then a TLS session from the proxy to the real endpoint.
The proxy needs to present itself to the client as valid for the real endpoint of the TLS connection. This is usually done by adding your own CA into the clients trust so you can sign any certificates required for the client -> proxy half. As you note, the connection from proxy -> endpoint is normally the easy part of that as it works like a normal client.
Two examples of not "tolerating" that interception are certificate pinning and client certificates.
Certificate pinning - The client validates extra information about the presented certificate beyond CA trust. Usually the x509 SHA-256 digest presented to the client. In this case the external entity doesn't enforce anything, you could modify the client to work.
Client certificates - Client cert authentication includes verification of the server certificate, so the forged proxy certificate will not be valid for the client cert. They are a pair. This would require a forged client cert for client -> proxy. Then the real client cert for proxy -> endpoint half.
So it's more convincing the client to tolerate the interception rather than the external endpoint.
Update the DHCP on your router, all done.
I have yet to see DNS/DoH “pinning”, and apps (browsers) will let your override it. Embedding DNS entries in apps is a bad idea (as opposed to cert pinning, which is about fixed trust, and a good idea). Given that sometimes this is going to be blocked, even if they did it would fall to the host resolver.
That said, which would be better suited to incorporate the other is an interesting question.
I am yet to hear of any examples of hardcoded DNS servers. I believe this to be too fragile to implement.