Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
1–10 of 14 posts
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#2Really cool idea, will be watching for this to hit production readiness.
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#3I'm only somewhat versed in networking and proxies - how is this different from something like SquidGuard?
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#4Subverting browser trust by installing a mitm root is not a good way to implement network policy. Many have tried to do this, such as AV vendors, and it generally ends badly.
Do I trust your TLS and certificate trust implementation over a mainline browsers?
Do you understand the nuances of implementing webPKI for browsers?
I think asking the user to give up traffic authentication and confidentiality for a privacy features are best be implemented as a browser extension without this trade-off.
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#5Subverting browser trust by installing a mitm root is not a good way to implement network policy. Many have tried to do this, such as AV vendors, and it generally ends badly. Do I trust your TLS and certificate trust implementation over a mainline browsers? Do you understand the nuances of implementing webPKI for browsers? I think asking the user to give up traffic authentication and confidentiality for a privacy fea…
Privaxy is matching chrome on https://badssl.com/dashboard/ and https://www.ssllabs.com/ssltest/viewMyClient.html except that Privaxy doesn't support older TLS versions and poorer ciphers.
It does not mean that there is not a single bug, but I do not think it is fair to completely discount this approach. Especially when the alternative is browser extensions which bring their fair share of trouble regarding trust, performance, limited capabilities or even security.
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#6Subverting browser trust by installing a mitm root is not a good way to implement network policy. Many have tried to do this, such as AV vendors, and it generally ends badly. Do I trust your TLS and certificate trust implementation over a mainline browsers? Do you understand the nuances of implementing webPKI for browsers? I think asking the user to give up traffic authentication and confidentiality for a privacy fea…
Privaxy is matching chrome on https://badssl.com/dashboard/ and https://www.ssllabs.com/ssltest/viewMyClient.html except that Privaxy doesn't support older TLS versions and poorer ciphers. It does not mean that there is not a single bug, but I do not think it is fair to completely discount this approach. Especially when the alternative is browser extensions which bring their fair share of trouble regarding trust, per…
I discount this approach. It is necessary but not sufficient to pass on simple browser SSL tests. There are other complexities that are best left to the browser to negotiate the session.
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#7Earlier quoted context omitted.
Privaxy is matching chrome on https://badssl.com/dashboard/ and https://www.ssllabs.com/ssltest/viewMyClient.html except that Privaxy doesn't support older TLS versions and poorer ciphers. It does not mean that there is not a single bug, but I do not think it is fair to completely discount this approach. Especially when the alternative is browser extensions which bring their fair share of trouble regarding trust, per…
I discount this approach. It is necessary but not sufficient to pass on simple browser SSL tests. There are other complexities that are best left to the browser to negotiate the session.
What are the things that you think are best handled by the browser while negotiating a session?
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#8Subverting browser trust by installing a mitm root is not a good way to implement network policy. Many have tried to do this, such as AV vendors, and it generally ends badly. Do I trust your TLS and certificate trust implementation over a mainline browsers? Do you understand the nuances of implementing webPKI for browsers? I think asking the user to give up traffic authentication and confidentiality for a privacy fea…
You have to give up trust in some way. I trust extensions running on all websites less than I trust a mitm proxy, because the mitm proxy doesn't have the ability to run code in the browser process itself. Its capabilities are similar or even higher and unlike intentional TLS mitm attacks, addon redirection is near impossible to find in the browser UI.
Reading through the code I see very little in the way of webPKI nuance and that's probably not a bad thing. Whatever special webPKI handling browsers do gets overridden by importing a user certificate anyway.
I don't know what will happen when this proxy encounters a host with a bad TLS certificate or when mutual TLS authentication is requested. My best guess is that it will 500 and send an empty page back. Proxies like Squid do the same, though I've also seen proxies generate certificates with the same errors (bad dates, bad domains, etc.) to allow the user to "fix" the problem. I don't think such problems are within the scope of the proxy as long as invalid HTTPS certificates aren't made valid by missing verification.
One additional benefit of this approach is that on a normal computer this system also allows blocking operating system tracking and such, not just browser traffic. Run such a proxy on the network edge and with four it five lines of nftables rules + proxy configuration to force devices to work through the proxy, you can apply the privacy protections on your entire network, or specific hosts if you add exclusion rules to some IP addresses.
On mobile this will be a lot harder because of the prevalence of TLS pinning. Android and iOS are nearly impossible to mitm without root access/jailbreaks even if you do it intentionally. I very much doubt that console and "smart" devices will work with such a system either.
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#9Subverting browser trust by installing a mitm root is not a good way to implement network policy. Many have tried to do this, such as AV vendors, and it generally ends badly. Do I trust your TLS and certificate trust implementation over a mainline browsers? Do you understand the nuances of implementing webPKI for browsers? I think asking the user to give up traffic authentication and confidentiality for a privacy fea…
You have to give up trust in some way. I trust extensions running on all websites less than I trust a mitm proxy, because the mitm proxy doesn't have the ability to run code in the browser process itself. Its capabilities are similar or even higher and unlike intentional TLS mitm attacks, addon redirection is near impossible to find in the browser UI. Reading through the code I see very little in the way of webPKI nu…
I use mitm proxies for my research, and very much understand their purpose. what I am objecting to is using it as a general purpose privacy policy network filter. That is not what a MiTM proxy should be used for.
The mitm proxy can inject js into the stream and fake any origin. At least the extension has limits of what it can access, and the code is fixed, unlike a proxy that can say something is anything from anywhere.
I am saying it is a bad thing, in when you put the browser in enterprise certificate mode with a MiTM cert you are disabling security features. All of the problems you have outlined are made worse by the proxy, either by failing open or failing closed.
You are right in that a lot of devices have countermeasures against these MiTM attacks and will not work for this purpose out of the box. This is another reason not to use this pattern for your general purpose tools.
Re: Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension
#10Earlier quoted context omitted.
I discount this approach. It is necessary but not sufficient to pass on simple browser SSL tests. There are other complexities that are best left to the browser to negotiate the session.
What are the things that you think are best handled by the browser while negotiating a session?
The connection parameters including encryption parameters and certificate from the origin.
There are a lot of weird rules in WebPKI you may miss, this is beyond a general purpose TLS library.
Enforcing Certificate Transparency rules or CAA records, is the proxy doing this?