Mitmproxy 11：HTTP/3を完全サポート
(mitmproxy.org)- QUICとHTTP/3トラフィックの比率が高まるなか、mitmproxy 11はHTTP/3をデフォルトで有効化し、最新のWebトラフィック分析範囲を拡大
- 透過プロキシとリバースプロキシだけでなく、WireGuardとlocal modeでもHTTP/3が動作し、さまざまなキャプチャ環境に適用可能
- ChromeはQUICでユーザーが追加したCertificate Authorityを信頼しないため、公開信頼証明書、コマンドラインスイッチ、HTTP/2へのフォールバックのいずれかを選ぶ必要がある
- DNS実装はHickory DNSベースに変更され、A/AAAA以外のクエリ、HTTPS records、DNS-over-TCP、hostsファイル制御、ECHキーの削除に対応
- ECHのようなプライバシー機能は中間者プロキシの証明書生成フローを難しくするが、mitmproxyはDNS応答の調整により動作可能性を維持
HTTP/3のサポート範囲
- mitmproxy 11はHTTP/3を透過プロキシとリバースプロキシモードでサポートする
- リバースプロキシでは、1つのmitmproxyインスタンスがTCPとUDPパケットの両方を受信し、転送されるHTTPバージョンを処理する
- コマンド例:
mitmproxy --mode reverse:https://http3.is
- コマンド例:
- WireGuardとlocal modeでもHTTP/3を利用できる
- コマンド例:
mitmproxy --mode wireguard mitmproxy --mode local
- コマンド例:
- Firefox、Chrome、複数のcURLビルド、その他のクライアントでテストし、互換性の問題を減らした
- HTTP/3サポートの作業は2022年にManuel MeitingerとMaximilian Hilsが開始し、mitmproxy 11でデフォルト有効になった
ChromeのQUIC証明書制約
- 現在知られている主な制限は、ChromeがQUICでユーザーが追加したCertificate Authorityを信頼しない点である
- ChromeでHTTP/3トラフィックを扱うには、次のいずれかが必要
- Let’s Encryptのような公開で信頼されている証明書を提供する
- 関連するコマンドラインスイッチ付きでChromeを実行する
- HTTP/2へフォールバックする動作を受け入れる
- Firefoxはこのような動作をしない
- HTTP/3のトラブルシューティングのヒントは#7025で確認できる
Hickory DNSベースの再実装
- DNS HTTPS recordsと**Encrypted Client Hello(ECH)**のようなプライバシー機能が登場し、mitmproxyのDNS処理の重要性が高まっている
- 既存のDNS実装は
getaddrinfoを使用していたため、制約があった- IPv4とIPv6アドレス用のA/AAAAクエリのみをサポート
- HTTP/3対応を知らせるHTTPS recordsのようなクエリに応答できなかった
- mitmproxy 11はDNSサポートを、RustベースのDNSライブラリであるHickory DNS上に再実装した
- Hickoryにより、Windows、Linux、macOSでOSのデフォルトネームサーバーを取得し、A/AAAA以外のクエリをそのネームサーバーへ転送する
- 新しい
dns_name_serversオプションで転送先ネームサーバーを指定できるmitmdump --mode dns --set dns_name_servers=8.8.8.8
hostsファイル制御とDNS-over-TCP
- Hickoryへの移行に合わせて、システムのhostsファイルを無視するオプションが追加された
- 新しい
dns_use_hosts_fileオプションを使うと、Linuxの/etc/hostsのようなhostsファイルを反映するかどうかを制御できる - mitmproxyの内部DNS解決もHickoryへ移行する計画で、その後は同一マシン上で特定ドメインを透過リダイレクトする際にこの機能が有用になる
- 現在はhostsファイルを常に考慮するため、同一マシンのリダイレクト設定でmitmproxyが自分自身へ再帰的に接続する可能性がある
- 動作例:
echo "192.0.2.1 mitmproxy.org" >> /etc/hosts mitmdump --mode dns dig @127.0.0.1 +short mitmproxy.org 192.0.2.1 mitmdump --mode dns --set dns_use_hosts_file=false dig @127.0.0.1 +short mitmproxy.org 3.161.82.13 - DNSは基本的にUDPを使うが、単一のUDPパケットに収まらないレコードを処理する際にはTCPが必要になる場合がある
- mitmproxy 11は任意のクエリタイプをサポートするようになり、メッセージサイズとTCP処理の重要性が高まったため、DNS-over-TCPも動作する
ECHキーの削除と証明書生成
- mitmproxyはユーザー指定の証明書がない場合、TLS ClientHelloの**Server Name Indication(SNI)**を使って有効な証明書を構成する
- SNIがないと、クライアントが信頼できる証明書を生成できない場合がある
- Encrypted Client Hello(ECH)は、クライアントがDNS HTTPS recordsでECHキーを取得した後、初期ClientHelloハンドシェイクメッセージをそのキーで暗号化する方式である
- DNSクエリとハンドシェイクがどちらも暗号化されると、受動的な中間者は対象ドメインを知ることができず、対象IPアドレスのみ確認できる
- 共有ホスティングとContent Delivery Networksでは、IPアドレスだけで対象ドメインを特定するのは難しい
- このプライバシー向上は、mitmproxyの証明書生成方式と衝突する
- mitmproxy 11はHTTPS recordsからECHキーを削除し、証明書生成に必要なドメイン情報を確保する
- クライアントは初期ハンドシェイクメッセージを暗号化するためのキーを取得できない
- mitmproxyは対象ドメインを把握し、一致する証明書を構成できる
- ECHはmitmproxyの利用をより難しくする可能性があるが、Web全体のプライバシーを高める変化と見ることができる
1件のコメント
Hacker News のコメント
Mitmproxy がまだ開発されていると知ってうれしい。このツールは間接的に自分のキャリアを作ってくれた
2011年にモバイルアプリのリクエストを傍受しながら API 開発を学んでいたとき、Airbnb API が Rails のマスアサインメント脆弱性（https://github.com/rails/rails/issues/5228）にさらされていることを見つけた。無害な属性をいくつか変えてみたあと会社に連絡したところ、それが面接につながり、その後は文字どおり歴史になった
ときにはドキュメントを読むより、既存の実装に mitmproxy をつないでみるほうが簡単なこともある
Chrome が QUIC でユーザーが追加した認証局を信頼しないという点が興味深い
リンク先の issue で Chrome チームは、「QUIC の傍受ソフトウェア／ハードウェアの配備を防ぐため、公開的に信頼されていない証明書を明示的に許可しない。そうしなければ長期的に QUIC プロトコルの進化可能性を損なう。公開信頼証明書ではない証明書に依存する用途は、QUIC ではなく TLS+TCP を使えばよい」と述べている
プロトコル進化を追っているわけではないが、カスタム証明書をブロックすることがどう 進化可能性 と結びつくのかはよく分からない。理由を知っている人がいるのか気になる
Chrome に少し修正した QUIC バージョンを入れ、Youtube のような場所で対応したうえで、その指標をもとに「本物の」標準変更を提案したり、自社サービスだけで特殊バージョンを動かし続けたりできる
カスタム証明書を許可すると、ZScaler ZIA のようなもので従業員トラフィックを中間者方式で検査している企業が、プロトコル変更時に壊れるリスクが生じる。データストリームが完全に暗号化され、中間機器から不透明であれば、Google はほぼ望みどおりにできる
関連概念: https://en.wikipedia.org/wiki/Protocol_ossification
拡張可能なプロトコルなら通常はクライアントとサーバーだけをアップグレードすればよいが、ミドルボックスがあると、潜在的に N 個の機器も一緒に更新しなければならない。ユーザーとサービス提供者には新機能導入の動機があるが、ミドルボックスの所有者にはない場合がある。その結果、プロトコルは進化しにくくなる
実装の詳細に強く依存するミドルウェアが多く、何かを少し変えるだけで意図せずユーザー体験を壊しやすかった。新バージョンでは同じような状況を避けようとしているように見える
HTTP/2 や HTTP/3 が リバースプロキシでだけサポートされ、実際の Web サーバーではサポートされていない場合でも利点があるのか気になる
JS/Python/Ruby の主流フレームワークの多くは新しい HTTP 標準をサポートしていない。そうなると Web サーバーがリバースプロキシ接続のボトルネックになるのではないか？
リバースプロキシと実際の Web サーバー間の接続は通常はるかに高速で安定しているため、その区間を HTTP/2 や HTTP/3 に上げても得られる利点はずっと小さい
HTTP を使う場合でも、リバースプロキシは実際のリモートクライアントよりバックエンドとはるかに速く接続を確立できる。だから遅い区間で HTTP/2 ストリームを使うことにはなお利点がある
ローカルマシンで実行し、低レベルプロトコルや Web セキュリティ関連のテストを行うためのツールだ
HTTP/2 以上では、複数の同時リクエストを1本の接続で処理する
まだフィンガープリンティングの問題が残っている。一般的なブラウザの TLS ハンドシェイクを模倣できるようになるまでは、Web の80%ほどで “Just a quick check...” や “Sorry, it looks like you're a bot” のようなページを見ることになる
https://github.com/mitmproxy/mitmproxy/issues/4575
Hickory に触れてくれてありがとう。人々がそれで何を作っているのかを見るのはいつも面白いし、よくできた仕事だ
こうしたものは本来、Python だけでは得にくかったはずだ
Mitmproxy を Privoxy/Proxomitron/Yarip のように使えるのか気になる
たとえば Ungoogled Chromium でブラウジングするときに Mitmproxy をプロキシにして、特定サイトの script タグを削除できるだろうか？ 性能にはどんな影響があるだろう？
Web ページを見るときに小さな遅延が何百回も積み重なると体感できるかもしれない
それでもこうした用途に関心がある人にとっては選択肢になり得る。技術的に妨げるものはない
JavaScript ファイルを書き換えるときにサブリソース完全性チェックに触れてしまう小さなリスクはあるが、実際に問題が起きればハッシュも書き換えて解決できそうだ
mitmproxy は Fiddler の代替になり得る？
https://docs.mitmproxy.org/stable/addons-overview/
うーん: https://github.com/mitmproxy/mitmproxy/issues/4170