セキュリティモデル
mqproxy は 信頼されたプロキシ モデルを採用します。mqproxy-client、mqproxy-server、そしてその間の MPQUIC コネクションは信頼されます。TCP プロキシモードと透過キャプチャモード (--mitm なし) では、アプリケーション↔オリジンの TLS はエンドツーエンドに保たれます (mqproxy は平文を一切見ず、生の TLS バイトを不透明にリレーします)。証明書ピンニングを行うアプリケーションも引き続き動作します。
HTTP リクエスト実行ゲートウェイは明示的な委譲モデルです — クライアントは、オリジン TLS を確立し (常に検証する) 信頼されたゲートウェイへ HTTP リクエストの実行を委譲します — 透過的な MITM ではありません。ゲートウェイリクエストは個別に認証されます (X-Mq-Auth、リクエストごと)。Authorization はオリジン用に予約され転送されますが、Cookie と X-Mq-* がゲートウェイを離れることは決してありません。
TLS MITM イングレス
TLS MITM イングレス (--mitm、オプトイン) は、オペレータの CA がローカルにインストールされたマネージドデバイス向けの オペレータ管理／同意済みエンドポイント モデルです — 企業プロキシや個人 VPN の姿勢であり、第三者への透過的な攻撃ではありません。クライアントはその CA からホストごとのリーフを偽造し、ブラウザの TLS を HTTP/2 として終端し、各リクエストをゲートウェイトンネルにマッピングします。
その信頼の前提:
- CA 秘密鍵が起点 です (
O_NOFOLLOW/O_CLOEXECで読み込まれ、暗号化されている、またはグループ／全体読み取り可能な場合は拒否)。 - ブラウザが提供する
X-Mq-*ヘッダは 常に除去 されます (制御として解釈されることは決してなく、クライアントが自身のx-mq-authを注入)。 - ベンダリングされた BoringSSL のシンボルは libcurl のシステム OpenSSL から 分離 されます。
- 機能は フェイルクローズ です (設定不備は起動エラーであり、決して暗黙のパススルーにならず、有界の ClientHello ドレインと H2 リソース制限を伴う)。
証明書ピンニングされたホストは --ignore-host(s) で除外でき、不透明にスプライスされてオリジンの本物の証明書がクライアントに届きます。運用上の詳細は TLS MITM ガイド を参照してください。
ライセンス
Apache-2.0。LICENSE を参照してください。
謝辞
- XQUIC (Alibaba) — QUIC/MPQUIC トランスポート。mp0rta フォーク 経由。
- BoringSSL — TLS バックエンド。