Mitmproxy 11: Full HTTP/3 Support • Hacker News Board

Re: Mitmproxy 11: Full HTTP/3 Support

#51

Post by persnickety » Sat, Oct 05, 2024, 2:26 PM UTC

superkuh wrote: post #50

persnickety wrote: post #49

Earlier quoted context omitted.

This doesn't have much to do with QUIC. If HTTP/3 was based upon another transport protocol, you'd have the exact same problems. You can use QUIC with custom certs without any trouble.

QUIC isn't just some transport protocol though: it's weird. These restrictions are based in the QUIC libs, not in UDP (which is the QUIC transport protocol). And while you can use QUIC with custom certs in a technical sense if you do the compile flags and build your own universe, 99.9999% of the people on Earth with their standard QUIC lib implementations (most use the same two) will be unable to connect to it.

I don't know what you're talking about, but I just imported a QUIC library and used it with a self-signed certificate. No extra steps required, either on the server or the client side.

Yes, the protocol is weird, compared to TCP. It has many extra features and one restriction, which is mandatory TLS, which I wouldn't even consider skipping anyway. Still nothing to do with ads.

Re: Mitmproxy 11: Full HTTP/3 Support

#52

Post by connicpu » Sat, Oct 05, 2024, 2:43 PM UTC

ahoka wrote: post #14

apitman wrote: post #9

Earlier quoted context omitted.

Also browsers limit the number of HTTP/1.1 requests you can have in flight to a specific domain

The limit is much higher for proxies, though.

With a reverse proxy the browser doesn't know it's talking to one

Re: Mitmproxy 11: Full HTTP/3 Support

#53

Post by cookiengineer » Sat, Oct 05, 2024, 2:47 PM UTC

persnickety wrote: post #51

superkuh wrote: post #50

Earlier quoted context omitted.

QUIC isn't just some transport protocol though: it's weird. These restrictions are based in the QUIC libs, not in UDP (which is the QUIC transport protocol). And while you can use QUIC with custom certs in a technical sense if you do the compile flags and build your own universe, 99.9999% of the people on Earth with their standard QUIC lib implementations (most use the same two) will be unable to connect to it.

I don't know what you're talking about, but I just imported a QUIC library and used it with a self-signed certificate. No extra steps required, either on the server or the client side. Yes, the protocol is weird, compared to TCP. It has many extra features and one restriction, which is mandatory TLS, which I wouldn't even consider skipping anyway. Still nothing to do with ads.

He was arguing about 99.99% of users being people that cannot use your stuff because chrome doesn't allow the use of snakeoil / self signed certs for QUIC, specifically, and TLS encryption is mandatory.

If you compare that to the graceful Connection: Upgrade handshake in http/1.1 and websockets, for example, this would've been much better because there is no isolation based on tools and libraries, only based on trust chain of the certificates. If a new version of the protocol breaks, it automatically falls back with both parties knowing about it. If QUIC protocol has changes on the client side, good luck finding that out.

Re: Mitmproxy 11: Full HTTP/3 Support

#54

Post by persnickety » Sat, Oct 05, 2024, 3:13 PM UTC

cookiengineer wrote: post #53

persnickety wrote: post #51

Earlier quoted context omitted.

I don't know what you're talking about, but I just imported a QUIC library and used it with a self-signed certificate. No extra steps required, either on the server or the client side. Yes, the protocol is weird, compared to TCP. It has many extra features and one restriction, which is mandatory TLS, which I wouldn't even consider skipping anyway. Still nothing to do with ads.

He was arguing about 99.99% of users being people that cannot use your stuff because chrome doesn't allow the use of snakeoil / self signed certs for QUIC, specifically, and TLS encryption is mandatory. If you compare that to the graceful Connection: Upgrade handshake in http/1.1 and websockets, for example, this would've been much better because there is no isolation based on tools and libraries, only based on trust…

Then the OP used a bad framing, because it was apparent to me that they opposed QUIC in general, not QUIC in Chrome.

Either way, I still fail to see how this relates to the original complaint that QUIC somehow leads to ads.

Re: Mitmproxy 11: Full HTTP/3 Support

#55

Post by rnhmjoj » Sat, Oct 05, 2024, 3:26 PM UTC

Unfortunately there is still the issue[1] of fingerprinting. Until it can spoof the TLS handshake of a typical browser, you get these "Just a quick check..." or "Sorry, it looks like you're a bot" pages on about 80% of the web.

[1]: https://github.com/mitmproxy/mitmproxy/issues/4575

Re: Mitmproxy 11: Full HTTP/3 Support

#56

Post by jeroenhd » Sat, Oct 05, 2024, 3:40 PM UTC

ozim wrote: post #41

febusravenga wrote: post #27

Only slightly related ... > Chrome does not trust user-added Certificate Authorities for QUIC. Interesting. In linked issue chrome team says: > We explicitly disallow non-publicly-trusted certificates in QUIC to prevent the deployment of QUIC interception software/hardware, as that would harm the evolvability of the QUIC protocol long-term. Use-cases that rely on non-publicly-trusted certificates can use TLS+TCP inst…

There is a case of Kazakhstan installing certs to MITM citizens couple years ago and bunch of cases where bad actors can social engineer people to install certain for. I think because of KZ case browsers and Chrome especially went for using only their own cert store instead of operating system one.

Browsers responded by blacklisting the Kazakh certificate the same way they blacklist the certificates that came with pre-installed spyware on laptops from shit vendors like Lenovo. You don't need to block all certificates to prevent against a well-known bad certificate.

Re: Mitmproxy 11: Full HTTP/3 Support

#57

Post by jeroenhd » Sat, Oct 05, 2024, 3:42 PM UTC

nilslindemann wrote: post #40

I wonder, can I use it like Privoxy/Proxomitron/Yarip? E.g. can I strip out script tags from specific sites, which I request with my browser (Ungoogled Chromium), using Mitmproxy as a Proxy? And how will this affect performance?

In theory: yes. In practice: mitmproxy is written in Python so there will be a delay because of the language not being all that fast. When you're visiting web pages with hundreds of small delays, you'll notice.

That said, for many people who care about this stuff, this could be an option. There's nothing preventing you from doing this technically speaking.

There's a small risk of triggering subresource integrity checks when rewriting Javascript files, but you can probably rewrite the hashes to fix that problem if it comes up in practice.

Re: Mitmproxy 11: Full HTTP/3 Support

#58

Post by mardifoufs » Sat, Oct 05, 2024, 5:16 PM UTC

superkuh wrote: post #46

jsheard wrote: post #38

Earlier quoted context omitted.

How does QUIC improve ad deliverability?

The entire protocol puts corporate/institutional needs first and foremost to the detriment of human person use cases. HTTP/3 makes all web things require CA TLS and means that if something in the TLS breaks (as it does every couple years with root cert expirations, version obsolecence, acme version obsolecence, etc) then the website is not accessible. Because there's no such thing as HTTP+HTTPS HTTP/3, self-signed HT…

If it was about institutional needs, surely it would make it easier to mitm for middleboxes? The biggest opposition to QUIC came from big corporations and other institutional players

Re: Mitmproxy 11: Full HTTP/3 Support

#59

Post by chgs » Sat, Oct 05, 2024, 5:35 PM UTC

mardifoufs wrote: post #58

superkuh wrote: post #46

Earlier quoted context omitted.

The entire protocol puts corporate/institutional needs first and foremost to the detriment of human person use cases. HTTP/3 makes all web things require CA TLS and means that if something in the TLS breaks (as it does every couple years with root cert expirations, version obsolecence, acme version obsolecence, etc) then the website is not accessible. Because there's no such thing as HTTP+HTTPS HTTP/3, self-signed HT…

If it was about institutional needs, surely it would make it easier to mitm for middleboxes? The biggest opposition to QUIC came from big corporations and other institutional players

Different players. Google and other ad companies are bigger than old companies trying to MITM their users.

Re: Mitmproxy 11: Full HTTP/3 Support

#60

Post by chgs » Sat, Oct 05, 2024, 5:37 PM UTC

persnickety wrote: post #54

cookiengineer wrote: post #53

Earlier quoted context omitted.

He was arguing about 99.99% of users being people that cannot use your stuff because chrome doesn't allow the use of snakeoil / self signed certs for QUIC, specifically, and TLS encryption is mandatory. If you compare that to the graceful Connection: Upgrade handshake in http/1.1 and websockets, for example, this would've been much better because there is no isolation based on tools and libraries, only based on trust…

Then the OP used a bad framing, because it was apparent to me that they opposed QUIC in general, not QUIC in Chrome. Either way, I still fail to see how this relates to the original complaint that QUIC somehow leads to ads.

QUiC was developed by ad as company