31–40 of 63 posts
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).
I fear that MITMing ads is a dead end: 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 c…
Run your own DoH filtering DNS server, I set this up a few months ago. DNS blocking is not obsoleted by transport encryption.
This approach is a natural escalation step as DNS-based blocking is getting increasingly difficult. But it's not without its drawbacks. For example, browsers tend to have by far the best TLS implementations. By MITMing yourself, you essentially trust the proxy's TLS implementation instead, which will receive much less scrutiny. There's a lot of precedent for TLS vulnerabilities introduced by middleboxes. If browser e…
Earlier quoted context omitted.
Run your own DoH filtering DNS server, I set this up a few months ago. DNS blocking is not obsoleted by transport encryption.
How do your force applications to use this server? I mean, even if you MITM the connection to the application’s preferred DoH server, the application probably checks the certificate of the DoH server and refuses to work at all if it can’t get a verified connection.
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.
What are the potential benefits of a ‘MITM’ approach, compared to other approaches like acting as DNS (like pihole)? 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 goo…
Most commercial firewalls for the last decade plus have such features.
I said it before and I will say it again, MITM for ad blocking is not a way forward. 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…
This approach is a natural escalation step as DNS-based blocking is getting increasingly difficult. But it's not without its drawbacks. For example, browsers tend to have by far the best TLS implementations. By MITMing yourself, you essentially trust the proxy's TLS implementation instead, which will receive much less scrutiny. There's a lot of precedent for TLS vulnerabilities introduced by middleboxes. If browser e…
Why is DNS based blocking getting difficult? You run a bind server and tell it what it can and cannot resolve. It can even listen on DoH so you get transport security between peer and local dns server.
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.
I said it before and I will say it again, MITM for ad blocking is not a way forward. 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…
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.
I fear that MITMing ads is a dead end: 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 c…
Run your own DoH filtering DNS server, I set this up a few months ago. DNS blocking is not obsoleted by transport encryption.
I fear that MITMing ads is a dead end: 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 c…
I wouldn't write it off - one possible trick here is to also MITM the DoH/DoQ server and disable ECH by removing the relevant records from the DNS response. We've just added DNS support to mitmproxy and this is a natural follow-up. :)