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

71–80 of 80 posts

Re: Mitmproxy 11: Full HTTP/3 Support

#71

Post by globular-toast »

mdaniel wrote: post #67
fud101 wrote: post #48

Earlier quoted context omitted.

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.

I may be feeding the trolls, but not only is there a sync mechanism, at least with Firefox you can self-host[1] such a thing, thereby doubly ensuring the data isn't used for something you disagree with If you're going to say that Firefox doesn't care about having users, point out its just stunningly stupid memory usage, blatantly stale developer tools (that one hurts me the worst because the Chrome dev-tooling is act…

I find Firefox's memory usage and dev tooling better than Chrome.

Re: Mitmproxy 11: Full HTTP/3 Support

#72

Post by essentia0 »

1vuio0pswjnm7 wrote: post #65
persnickety wrote: post #54

Earlier quoted context omitted.

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.

"Either way, I still fail to see how this relates to the original complaint that QUIC somehow leads to ads." "HTTP/3 uses QUIC, a transport layer network protocol which uses user space congestion control over the User Datagram Protocol (UDP). The switch to QUIC aims to fix a major problem of HTTP/2 called "head-of-line blocking": because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recove…

HTTP/1.1 is no different from HTTP/2 and even HTTP/3 when it comes to multiple domains. The optimization strategies are all aimed at solving simultaneous resource requests from a single host (not domain but close enough) - should be obvious when you consider that each host requires at least one separate socket connection anyway.

In practice http/1.1 with 1 connection per request even encouraged making more domains/subdomains if you wanted to have more simultaneous requests

Re: Mitmproxy 11: Full HTTP/3 Support

#73

Post by codetrotter »

hedora wrote: post #18
codetrotter wrote: post #16

Earlier quoted context omitted.

> mitmproxy is not a reverse proxy for any production purpose At a startup I was working on a few years ago, I set up mitmproxy in dev and eventually if memory serves right I also sometimes enabled it in prod to debug things. That being said, we did not have a lot of users. We had in fact very very few users at the time.

I’ve been patiently waiting for someone to write a howto that uses mitmproxy to transparently obtain acme certificates for any web servers that are behind it. I’d totally pay a cloud provider to just do this and forward requests to my port 80 or 443 with self signed certificates. Https+acme is already open to this attack vector, so why inconvenience myself by pretending it is not?

In our setup, TLS was already being terminated by Nginx or Caddy (I don’t remember which, but it was one of those two) sitting in front of another web server on the same host.

So inserting mitmproxy into the setup was just a case of putting it between the Nginx or Caddy that did TLS termination, and the web server that served the backend API. So to mitmproxy it was all plain HTTP traffic passing through it, locally on the same machine.

I bound the mitmweb web UI to the VPN interface so that us devs could connect to the dev server with VPN and then have access to the mitmweb web UI to inspect requests and responses.

Re: Mitmproxy 11: Full HTTP/3 Support

#74

Post by fud101 »

mdaniel wrote: post #67
fud101 wrote: post #48

Earlier quoted context omitted.

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.

I may be feeding the trolls, but not only is there a sync mechanism, at least with Firefox you can self-host[1] such a thing, thereby doubly ensuring the data isn't used for something you disagree with If you're going to say that Firefox doesn't care about having users, point out its just stunningly stupid memory usage, blatantly stale developer tools (that one hurts me the worst because the Chrome dev-tooling is act…

Don't care about self hosting. That's not a feature to me, it's a burden. I would rather some cloud provider do that for me, thankfully Google does it for free and the convenience is much appreciated. It's the same reason i'd put my personal code in Github than some hard drive in the basement which may die anytime.

Re: Mitmproxy 11: Full HTTP/3 Support

#75

Post by mdaniel »

fud101 wrote: post #74
mdaniel wrote: post #67

Earlier quoted context omitted.

I may be feeding the trolls, but not only is there a sync mechanism, at least with Firefox you can self-host[1] such a thing, thereby doubly ensuring the data isn't used for something you disagree with If you're going to say that Firefox doesn't care about having users, point out its just stunningly stupid memory usage, blatantly stale developer tools (that one hurts me the worst because the Chrome dev-tooling is act…

Don't care about self hosting. That's not a feature to me, it's a burden. I would rather some cloud provider do that for me, thankfully Google does it for free and the convenience is much appreciated. It's the same reason i'd put my personal code in Github than some hard drive in the basement which may die anytime.

Perhaps you interpreted my comment as that one must self-host, versus what I intended which is "you can use theirs, or you can use yours, depending on your paranoia level". I thought to include that distinction because some folks believe that Chrome is merely a data exfiltration and ad delivery vector created by the biggest Ad Tech on the planet and therefore don't trust them to be good stewards of arguably the most sensitive thing a modern user creates: browser history

Of course one can just use Firefox Sync out of the box https://support.mozilla.org/en-US/kb/sync>; even Mozilla has not yet stooped so low as to require opening a terminal just to use Firefox or its Sync component

Re: Mitmproxy 11: Full HTTP/3 Support

#76

Post by account42 »

tecleandor wrote: post #64
dstroot wrote: post #33

Earlier quoted context omitted.

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

Well, my company is doing it already. They split VPN traffic depending on the target domain (mostly for benign reasons), and that can't do it with QUIC, so they have to block QUIC traffic.

What benign reason could there possibly be that isn't better based on IP addresses rather than domains.

Re: Mitmproxy 11: Full HTTP/3 Support

#77

Post by account42 »

markasoftware wrote: post #10
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?

the transport between reverse proxy backend is not always http, eg python w/ uwsgi and php w/ fastcgi. And even when it is HTTP, as other commenters said, the reverse proxy is able to handshake connections to the backend much more quickly than an actual remote client would, so it's still advantageous to use http/2 streams for the slower part of the connection.

> the transport between reverse proxy backend is not always http, eg python w/ uwsgi and php w/ fastcgi.

That's just called a web server and not a reverse proxy then. Both are just evolutions of CGI.

Re: Mitmproxy 11: Full HTTP/3 Support

#78

Post by account42 »

rnhmjoj wrote: post #55

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

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

Evidently Firefox is not a typical browser anymore.

Re: Mitmproxy 11: Full HTTP/3 Support

#79

Post by fud101 »

mdaniel wrote: post #75
fud101 wrote: post #74

Earlier quoted context omitted.

Don't care about self hosting. That's not a feature to me, it's a burden. I would rather some cloud provider do that for me, thankfully Google does it for free and the convenience is much appreciated. It's the same reason i'd put my personal code in Github than some hard drive in the basement which may die anytime.

Perhaps you interpreted my comment as that one must self-host, versus what I intended which is "you can use theirs, or you can use yours, depending on your paranoia level". I thought to include that distinction because some folks believe that Chrome is merely a data exfiltration and ad delivery vector created by the biggest Ad Tech on the planet and therefore don't trust them to be good stewards of arguably the most…

Again, I don't care that Firefox wants me to build up my profile on one device. Then transfer that to some other device. I already have my profile. Let me login to my chrome profile and use it. I don't want to buy into your shitty ecosystem even if it gives freedom (that i dont want or care about).

Re: Mitmproxy 11: Full HTTP/3 Support

#80

Post by tecleandor »

account42 wrote: post #76
tecleandor wrote: post #64

Earlier quoted context omitted.

Well, my company is doing it already. They split VPN traffic depending on the target domain (mostly for benign reasons), and that can't do it with QUIC, so they have to block QUIC traffic.

What benign reason could there possibly be that isn't better based on IP addresses rather than domains.

When this kind of VPN clients do split traffic based on domains, they do it with some tricks, either via DNS or capturing traffic on the browser, or similar things.

But for doing split VPN with IP addresses they need to create an IP route in the VPN client. If you just have a couple IPs, it's fine, but if you have a couple hundred targets, you're gonna break some guys Windows or Mac machine sending that huge routing table.

Also, there are targets that change IP addresses. For example, AWS Elastic Load Balancers change IP addresses sometimes (if nothing have changed in the last years, haven't deployed ELBs in a while...).

Post reply on HN