Possible to playback HTTP/2 with upstream cert sniffing disabled (upstream_cert=false)

#1

We’re using mitmproxy to playback recorded sessions.

The live TLS connections to upstream servers were introducing noise into our performance tests so we’re attempting to disable them with the “upstream_cert=false” or “–no-upstream-cert” option (using mitmdump 2.02).

However I noticed that this prevents HTTP/2 playback (http1.1 chosen during alpn).

Is there any way to playback HTTP/2 without connecting to the live upstream servers?

#2

Reading up on how ALPN is implemented (in the TLS handshake), my question becomes,
“Is there any way that I can record the server’s choice of h2 as the protocol in the mitmdump session recording?”

#3

Can anyone confirm whether it’s possible to playback HTTP/2 with upstream cert sniffing disabled?

This would be very helpful for us (offline playback).

If it’s not supported I’d be happy to write up feature request use-case.

#4

Hi @andrewMoz,

This is a tricky problem we currently don’t have a good answer for. We currently don’t do HTTP/2 <-> HTTP/1 translation, so when we negotiate HTTP/2 with the client we kind of need to make sure that the server supports it as well (as we can’t determine if a replay will happen at this point).
One viable approach might be to provide some form of ALPN callback to the scripting interface, but we haven’t implemented anything of that sort yet.

If you really really do need HTTP/2, one viable workaround might be to put mitmproxy into upstream/reverse proxy mode and point to some dummy server running on the same machine that advertises h2. This will trick mitmproxy into thinking that upstream does support it.

#5

Thank you @mhils.

We do really need HTTP/2 (when supported by a given server) because we’re measuring performance and in many cases the difference between HTTP/1 and 2 is significant.

Maybe a dummy server server solution could work for us – thanks for the idea.

Cheers.

#6

@mhils could we just mock calls to get_alpn_proto_negotiated() to force h2 ?

setting up a local server just to give back a valid answer to mitmproxy sounds like more work than just forcing the decision inside mitmproxy. Or is this what you meant by ALPN callback ? happy to work on a patch if you could point me into the right direction.

Thanks!

Tarek

#7

I’ve added https://github.com/mitmproxy/mitmproxy/issues/3536 and working on it, if someone has any hints !

Cheers
Tarek