4 ms·

Show HN: Privaxy – Like uBlock but through a MitM proxy and no browser extension

14 points by pierrebarre 4y ago

pull_my_finger 4y ago
Seems to be dangerously encroaching on the namespace of Privoxy[1] which offers a somewhat overlapping solution. [1]: https://www.privoxy.org/ https://www.privoxy.org/
russdpale 4y ago
Really cool idea, will be watching for this to hit production readiness.
Z_I_F_F 4y ago
I'm only somewhat versed in networking and proxies - how is this different from something like SquidGuard?
rfd4sgmk8u 4y ago
Subverting 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.
- pierrebarre 4y ago
  Privaxy is matching chrome on https://badssl.com/dashboard/ https://badssl.com/dashboard/ and https://www.ssllabs.com/ssltest/viewMyClient.html 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.
  - rfd4sgmk8u 4y ago
    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.
    - pierrebarre 4y ago
      What are the things that you think are best handled by the browser while negotiating a session?
      - rfd4sgmk8u 4y ago
        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?
        ThePowerOfFuet 4y ago
        Which browser enforces CAA? it's a certificate misissuance, but AFAIK it's not up to the browser.
- jeroenhd 4y ago
  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.
  - rfd4sgmk8u 4y ago
    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.

14 points by pierrebarre 4y ago

Seems to be dangerously encroaching on the namespace of Privoxy[1] which offers a somewhat overlapping solution. [1]: https://www.privoxy.org/ https://www.privoxy.org/

russdpale 4y ago

Really cool idea, will be watching for this to hit production readiness.

Z_I_F_F 4y ago

I'm only somewhat versed in networking and proxies - how is this different from something like SquidGuard?

rfd4sgmk8u 4y ago

Subverting 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.

pierrebarre 4y ago
Privaxy is matching chrome on https://badssl.com/dashboard/ https://badssl.com/dashboard/ and https://www.ssllabs.com/ssltest/viewMyClient.html 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.
- rfd4sgmk8u 4y ago
  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.
  - pierrebarre 4y ago
    What are the things that you think are best handled by the browser while negotiating a session?
    - rfd4sgmk8u 4y ago
      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?
      - ThePowerOfFuet 4y ago
        Which browser enforces CAA? it's a certificate misissuance, but AFAIK it's not up to the browser.
jeroenhd 4y ago
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.
- rfd4sgmk8u 4y ago
  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.