Support for HTTP/3 and QUIC

[Aniketh01]

With the advent of the new transport protocol QUIC, a lot of the network traffic would be shifting to speak HTTP/3 soon. A number of services are already speaking HTTP/3 already. It would be nice to if mitmproxy would support these protocols as well.

The current available python-based QUIC/HTTP3 library to use would be aioquic: https://github.com/aiortc/aioquic/.

Would be happy to discuss more this and the future work this could entail :)

[mhils]

That's definitely something that's on our radar. The changes involved are quite nontrivial, but @meitinger has a working fork with QUIC support at https://github.com/Meitinger/mitmproxy. We will probably take a closer look once #1775 has landed.

[Aniketh01]

Thanks for letting me know. @meitinger Is there a working commit with https://github.com/Meitinger/mitmproxy where I can test, listen to the QUIC and HTTP/3 traffic? So far I have tested, and wasn't able to capture any QUIC traffic. Am I missing something here?

[alt-glitch]

@Aniketh01 Did you manage to get this fork to work? Moreover how did you test QUIC traffic? I have installed that fork in an Ubuntu VM to try it out but haven't been able to find a way to generate QUIC traffic.

[daMatz]

Is there any news about HTTP/3 support? Would love to see it for mitmproxy but as QUIC is based on UDP it seems like a bigger task, right?

[ericbeland]

Saw this comment go by, which spurred my curiosity on how popular HTTP/3 is? When this was opened, HTTP/3 was probably 2 or 3 percent of all internet traffic, but now is about 24 percent.

[j-h-a]

@ericbeland yes, totally, and many services can benefit such as video-streaming via CDNs. The lack of support in popular tools is a good reason to not use it yet. Engineers are making technical decisions all over the world, and part of that process is "how easy will my thing be to test if I use this tech?". For me, not being able to use mitmproxy to inspect what's going on is a deal-breaker for QUIC when building mobile apps. At least for now. It's likely we will adopt it eventually, but lack of support in tools is definitely restricting that growth. All good reasons this should be raised in priority.
(btw, I love mitmproxy - many thanks to all its contributors).

[mhils]

QUIC remains a bit tricky to implement for us.

• Ideally we'd use OpenSSL, but OpenSSL still does not expose reasonable APIs (https://daniel.haxx.se/blog/2021/10/25/the-quic-api-openssl-will-not-provide/).
• One alternative is aioquic, which I'm not too enthusiastic about (yet). Given the lack of OpenSSL APIs it implements lots of low-level stuff, including some parts written in C. I don't think there've been any security reviews of the codebase and the bus factor is 1. I do think it's a great effort, but I'm not feeling confident enough to depend on it in mitmproxy.
• Finally, we could consider developing Python bindings for one of the Rust implementations (Quiche/Quinn/Neqo). This would be fun to look into, the downside of that approach is that it brings tons of additional stuff we need to maintain - cross-platform wheel builders, etc. etc.

So yes - as much fun as it would be, I can't justify taking multiple months off to work on this at the moment. If you work for a company is interested in sponsoring (parts of) the efforts in mitmproxy, please feel free to get in touch. Outside of that I don't see us adopting QUIC super soon unfortunately.

[ericbeland]

@mhils Do you have a ballpark for what sponsoring that effort would cost? It might be helpful for conversations in organizations that depend on mitmproxy but are longing for QUIC support.

[hellodword]

Finally, we could consider developing Python bindings for one of the Rust implementations (Quiche/Quinn/Neqo). This would be fun to look into, the downside of that approach is that it brings tons of additional stuff we need to maintain - cross-platform wheel builders, etc. etc.

Quiche has C API, so maybe it's much easier than other implementations for using in Python.

as much fun as it would be, I can't justify taking multiple months off to work on this at the moment.

Totally understand.

I've been following the QUIC/HTTP3 & MITM issue for a year.

As it's a great challenge for "traditional" MITM tools, maybe we can open an issue and mark it as help wanted.

[mhils]

@mhils Do you have a ballpark for what sponsoring that effort would cost? It might be helpful for conversations in organizations that depend on mitmproxy but are longing for QUIC support.

Highly depends on timing (does OpenSSL have reasonable APIs yet?) and scope (interop with other HTTP versions, replay functionality, ...). Realistically it will take at least a few months of full-time work, so take your usual consulting rate and you'll have an approximate ballpark figure. There are of course lower hanging fruits, for example building an "sslsplit for QUIC" outside of mitmproxy. It may make a lot of sense to just build that first.

Quiche has C API, so maybe it's much easier than other implementations for using in Python.

Thanks for the pointer. I've also had some great experiences with using PyO3 on smaller projects, so I think the interop story is definitely something that can be solved. It's definitely worth to evaluate both approaches. :)

[meitinger]

There is now a PR for DNS (#5232). These changes also include support for UDP. Once they get finalized and merged, I'll start work on updating the (now mostly defunct) fork mentioned earlier for mitmproxy's new sansio implementation.

[meitinger]

Draft PR #5435 for QUIC support in mitmproxy is finally here. So far reverse mode for H3 and raw stream relay have been implemented. For those who are interested: Please comment, test and report bugs, thanks :)

[RenjieTang]

If I'm running mitmpxoxy in non-http3 mode, and the application tries to speak HTTP/3, what's the expected behavior?
Do we expect the UDP traffic to be excluded from the dump? Or does mitmproxy reject to do QUIC handshake and force the application to fallback to TCP?

[meitinger]

If I'm running mitmpxoxy in non-http3 mode, and the application tries to speak HTTP/3, what's the expected behavior?

If no HTTP3 mode is specified, no UDP socket will be opened. If mitmproxy acts as a reverse proxy, the application should fall back to HTTP1/2 (unless any alt-svc points to a valid HTTP3 service on the same host).
In transparent mode, you might want to block certain UDP traffic, if otherwise UDP packets pass mitmproxy unfiltered.

[mhils]

Some excellent news: The NLnet Foundation is sponsoring the development of HTTP/3 for mitmproxy. We aim to have a first experimental release out very shortly! 😃

[3052]

In transparent mode, you might want to block certain UDP traffic, if otherwise UDP packets pass mitmproxy unfiltered.

how do you do that?

[alyfreym]

Any update?

[mhils]

https://mitmproxy.org/posts/releases/mitmproxy10/

[rew1nter]

There's no support for HTTP3 forward proxying right?

[mhils]

We currently support HTTP/3 reverse proxying only. Support for transparent mode, WireGuard mode, and local redirect mode is coming next. :)

[rew1nter]

Support for transparent mode,

I didn't understand that. Will this include the forward proxying ?

[mhils]

The term "forward proxy" does not have a super well-defined meaning. Check out https://docs.mitmproxy.org/stable/concepts-modes/ for what I mean by transparent mode.

A "regular mode" HTTP/3 proxy (where you configure an HTTP/3 proxy in your client) will definitely come last. AFAIK client support for that is mostly not there yet.

[felixshing]

Hi I am new in this area. I would like to ask can we use mitmproxy to decrypt QUIC traffic right now? Specifically, my clients are iPhone and Apple Vision Pro, and they use FaceTime, which transmits content via QUIC. I can set up a WiFi AP on MacBook or Linux. Is it possible for me to decrypt the QUIC content in this setup?