反向代理模式下的mitmproxy + ALPN

mitmproxy in reverse proxy mode + ALPN

最近我需要在启用 HTTP/2 的情况下对本地 nginx 服务器设置进行 mitmproxy,所以我浏览了 mitmproxy 的 Modes Of operation 文档页面并像这样启动它:

./mitmdump --mode reverse:https://localhost -p 8080 --ssl-insecure

此命令以侦听端口 8080 的反向代理模式启动它。此外,它不会验证上游 TLS 证书。

通过Firefox访问https://localhost:8080后,看到nginx回答使用HTTP/1.1。此外,在 Wireshark 中,我看到从 mitmproxy 到 nginx 服务器的 TLS ClientHello 不包含 ALPN 扩展字段,而从 Firefox 到 mitmproxy 的 ClientHello 确实包含它。我的假设是 mitmproxy 没有正确反映 ALPN 协商,所以我开始寻找解决方案并找到以下 mitmproxy option:

connection_strategy - Determine when server connections should be established. When set to lazy, mitmproxy tries to defer establishing an upstream connection as long as possible. This makes it possible to use server replay while being offline. When set to eager, mitmproxy can detect protocols with server-side greetings, as well as accurately mirror TLS ALPN negotiation. Default: eager Choices: eager, lazy

据我了解,“准确镜像 TLS ALPN 协商”正是我所需要的,但因为它是 mitmproxy 的默认行为,而且正如我所描述的那样,它不起作用,我决定检查一下如果我将它设置为懒惰会发生什么:

./mitmdump --mode reverse:https://localhost -p 8080 --ssl-insecure --set connection_strategy=lazy

它奏效了。我可以看到 nginx 使用 HTTP/2.

进行响应

有人能指出为什么我对 connecttion_strategy 选项的理解是错误的吗?它是否与反向代理的工作方式有关?

您已经正确理解了所有内容,不镜像 ALPN 是我们当前实施中的一个错误。我在这里提交了一个问题:https://github.com/mitmproxy/mitmproxy/issues/5369。 :)