Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mitmproxy 11: Full HTTP/3 Support

mitmproxy.org

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Mitmproxy 11: Full HTTP/3 Support

#41

Post by ozim »

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.

Re: Mitmproxy 11: Full HTTP/3 Support

#42

Post by jeltz »

Onavo wrote: post #4

Do http/2 and http/3 offer any benefits if they are only supported by the reverse proxy but not the underlying web server? Most mainstream frameworks for JS/Python/Ruby don't support the newer http standards. Won't the web server be a bottleneck for the reverse proxied connection?

Yes, for http/3 since it handles network issues better. Http/2 is of more doubtful value since it can choke really bad on packet loss.

Re: Mitmproxy 11: Full HTTP/3 Support

#43

Post by RamRodification »

envoked wrote: post #22

It’s great to see that Mitmproxy is still being developed - it indirectly made my career. Back in 2011, I was using it to learn API development by intercepting mobile app requests when I discovered that Airbnb’s API was susceptible to Rails mass assignment ( https://github.com/rails/rails/issues/5228 ). I then used it to modify some benign attributes, reached out to the company, and it landed me an interview. Rest is…

> Rest is history

;)

Re: Mitmproxy 11: Full HTTP/3 Support

#44

Post by josephg »

dstroot wrote: post #33
filleokus wrote: post #31

Earlier quoted context omitted.

If I were to guess, it's to allow Google freedom in experimenting with changes to QUIC, since they control both the client and large server endpoints (Google Search, Youtube etc). They can easily release a sightly tweaked QUIC version in Chrome and support it on e.g Youtube, and then use metrics from that to inform proposed changes to the "real" standard (or just continue to run the special version for their own stuf…

Companies that use something like Zscaler would be highly likely to block QUIC traffic to force it onto TCP.

That’s exactly what Google is hoping will happen. If QUIC is blocked entirely, there’s no risk that small tweaks to the quic protocol will break Google’s websites for any companies using these tools.

Re: Mitmproxy 11: Full HTTP/3 Support

#45

Post by josephg »

intelVISA wrote: post #39
jsheard wrote: post #38

Earlier quoted context omitted.

How does QUIC improve ad deliverability?

> 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 For Chrome at least..!

That has nothing to do with ad deliverability.

Re: Mitmproxy 11: Full HTTP/3 Support

#46

Post by superkuh »

jsheard wrote: post #38
intelVISA wrote: post #36

Earlier quoted context omitted.

QUIC exists to improve ad deliverability, to grant user freedom would counteract that goal.

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 HTTPS HTTP/3, or even, as in this case, custom CA TLS HTTP/3. It's designed entirely around corporate/institutional needs and is a terrible protocol for human people. HTTP+HTTPS websites can last decades without admin work. HTTP/3 websites can only last a few years at most.

Re: Mitmproxy 11: Full HTTP/3 Support

#47

Post by JeremyNT »

envoked wrote: post #22

It’s great to see that Mitmproxy is still being developed - it indirectly made my career. Back in 2011, I was using it to learn API development by intercepting mobile app requests when I discovered that Airbnb’s API was susceptible to Rails mass assignment ( https://github.com/rails/rails/issues/5228 ). I then used it to modify some benign attributes, reached out to the company, and it landed me an interview. Rest is…

To this day it remains incredibly useful to me, and weirdly obscure to people who I would've thought should know better.

Sometimes it's easier to use mitmproxy with an existing implementation than to read the documentation!

Re: Mitmproxy 11: Full HTTP/3 Support

#48

Post by fud101 »

globular-toast wrote: post #30
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…

It can seem confusing but it all makes sense when you realise Chrome is designed to work for Google, not for you. I remember people switching their Grandmas to Chrome 15 years ago when they could've chosen Firefox. Many of us knew this would happen, but convenience and branding is everything, sadly.

I don't really think Firefox cares about having users. The one killer feature Chrome has is being able to access all your state by logging into your Chrome account. Firefox refuses to provide this basic service which will allow you to seamlessly use your data on Firefox and then eventually stop using Chrome. I wish Firefox nothing but the worst.

Re: Mitmproxy 11: Full HTTP/3 Support

#49

Post by persnickety »

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…

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.

Re: Mitmproxy 11: Full HTTP/3 Support

#50

Post by superkuh »

persnickety wrote: post #49
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…

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.

Post reply on HN