What does it mean when:
"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?
Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
51–60 of 63 posts
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#52Some people seem to be saying that apps and devices bypass your DNS settings.
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.
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#53I 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…
D. Create a whole bunch of VMs with browsers and “fake users” to DoS the whole ad-based business model.
(Note: DoS not literally, of course, but by feeding it with so much fake metrics that the signal - metrics for actual, live users - gets lost in the noise.)
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.
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#54I 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…
Does AdGuard also use this approach?
https://kb.adguard.com/en/general/how-malware-protection-wor...
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#55Earlier quoted context omitted.
OP is stating that "apps and devices" may circumvent DNS blocking by resorting to DoH. You can run your own DoH server, and you can even advertise it via your DHCP server, but clients ("apps and devices") do not need to accept the supplied servers for their own configuration.
A lot of things are possible, but are they done? I am yet to hear of any examples of hardcoded DNS servers. I believe this to be too fragile to implement.
League of Legends hardcodes 8.8.8.8.
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#56Earlier quoted context omitted.
A lot of things are possible, but are they done? I am yet to hear of any examples of hardcoded DNS servers. I believe this to be too fragile to implement.
League of Legends hardcodes 8.8.8.8.
Thank you for the example, probably 53/udp, which one can set up a NAT rule to direct all outgoing 53 to the local filtering DNS resolver.
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#57I 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…
4. Deliver ads from same host as content (like Twitter, YouTube)
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#58What does it mean when: "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?
TLS connections are tunnelled through proxies directly to the endpoint (HTTP CONNECT method) rather than the "client request to proxy" followed by "proxy request to endpoint" method of proxying.
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.
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#59Some people seem to be saying that apps and devices bypass your DNS settings. 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.
It's possible. Applications don't have to rely on the OS provided mechanisms to lookup names, or even rely on DNS to get an IP for something.
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).
Re: Show HN: Privaxy – Adblocking / tracker blocking by MITMing HTTPS traffic
#60Earlier quoted context omitted.
OP is stating that "apps and devices" may circumvent DNS blocking by resorting to DoH. You can run your own DoH server, and you can even advertise it via your DHCP server, but clients ("apps and devices") do not need to accept the supplied servers for their own configuration.
A lot of things are possible, but are they done? I am yet to hear of any examples of hardcoded DNS servers. I believe this to be too fragile to implement.
They don't even have to be hardcoded, they just have to ignore anything you specify or not give you any option to specify your own. As long as a device manufacturer can push updates to your device (even by IP address) they can regularly update their chosen DNS servers when needed. Honestly though, for many devices I doubt they'd even bother. Companies seem to have little trouble taking the position that if your device is more than a few years old you're insane for expecting them to still support it and you should have already thrown it away and bought another one.