[rfd4sgmk8u]

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.

[jeroenhd]

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]

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.

[jeroenhd]

That's the thing though, uBlock rules can also inject scripts and addons can intercept and replace contents of network calls through the injected code.

I think mitm proxies should be used for whatever people find them suitable. I don't have a problem with this use case, especially as this is clearly something you will only get working with a moderate understanding of the underlying concepts.

Tools like Privoxy have existed for years and I don't know why you wouldn't trust a proxy over an addon. Just don't set it up for other people who can't make the risk/reward judgement (though the same goes for adblockers and other extensions).

[ThePowerOfFuet]

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

No, but it is absolutely able to inject code which will then be run in the browser.

[pierrebarre]

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.

[rfd4sgmk8u]

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]

What are the things that you think are best handled by the browser while negotiating a session?

[rfd4sgmk8u]

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]

Which browser enforces CAA?

it's a certificate misissuance, but AFAIK it's not up to the browser.