HTTPS復号（中間者攻撃、MitM）

ChuteはMitMによってHTTPSトラフィックを復号できます。詳細についてはWikipediaの記事を参照してください。iPhone、Apple TV、Androidではこれはライセンスが必要な機能で、エンジンがそれを強制します。ライセンスが無ければ、設定に何と書かれていても何も復号されません。ライセンスと有効化を参照してください。

証明書ジェネレーターは、デバッグ用の新しいCA証明書を生成し、その証明書をシステムに信頼させるのに役立ちます。Chute MacおよびChute iOSの設定エディターで利用できます。この証明書はローカルで生成され、プロファイルファイルとシステムキーチェーンにのみ保存されます。新しい証明書の鍵はOpenSSLを使用してランダムに生成されます。Chute Androidにジェネレーターはありません。エディターのMitM → CAを設定で既存のPKCS#12を読み込み、CAをインストールでそのCA証明書をAndroidの証明書インストーラに渡します — CA証明書のインストールと信頼を参照してください。

既存のCA証明書も使用できます。証明書をパスフレーズ付きのPKCS#12形式（.p12）でエクスポートしてください。パスフレーズは空にできませんので注意してください。Chuteはパスフレーズの無いPKCS#12の読み込みを拒否します。"base64"コマンドを使用してbase64文字列にエンコードし、以下の設定を設定ファイルに追加してください。

[MITM]
enable = true
ca-p12 = MIIJtQ.........
ca-passphrase = password
hostname = *google.com

Chuteはここで宣言されたホストへのトラフィックのみを復号するので、必ず指定してください。すべてのプラットフォームで、有効な[MITM]セクションがhostnameを宣言していなければ何も復号されません。キーがまったく無い場合も、hostname-disabledのエントリしか無い場合も同じです。HTTPプロキシ経由では、CONNECTで届いたHTTPSだけが復号されます。平文HTTPリクエストは、ホストがhostnameに書かれていても通常どおり転送されます。

ワイルドカード文字と?がサポートされています。なお、?はルールに`も含まれる場合にのみワイルドカードとして機能します。?`のみを含むルールはリテラルとして比較されます。

• プレフィックス-を使用してホスト名を除外します。エントリは書かれた順に照合され、最初にマッチしたものが結果を決めます。そのため除外は、それが切り出す範囲を含むエントリより前に置く必要があります: hostname = -*.apple.com, * はapple.comを復号しませんが、hostname = *, -*.apple.com はapple.comを復号します。
• デフォルトでは、ポート443へのリクエストのみが復号されます。
  • サフィックス:portを使用して他のポートを許可します。
  • サフィックス:0を使用して全てのポートを許可します。

例:

• -*.apple.com: *.apple.comへのポート443での全てのリクエストを除外します。
• www.google.com: www.google.comへのポート443でのMitMを許可します。
• www.google.com:8080: www.google.comへのポート8080でのMitMを許可します。
• www.google.com:0: www.google.comへの全ポートでのMitMを許可します。
• *: ポート443での全てのホスト名に対するMitMを許可します。（非推奨）
• *:0: 全ポートでの全てのホスト名に対するMitMを許可します。（非推奨）

4 つのキーワードは宛先のクラス全体を表し、名前と同じく-プレフィックスと:ポートサフィックスを付けられます。<ip-address>（IPリテラルへの接続すべて）、<ipv4-address>、<ipv6-address>、<simple-hostname>（intranetのようなドットを含まない名前）です。hostname = -<simple-hostname>, *は単一ラベルの名前以外をすべて復号し、hostname = <ip-address>はアドレスへの接続だけを復号します。アドレスのキーワードが適用されるのは、HTTPプロキシ経由でアドレスに対して行われるCONNECTだけです。TUNの接続はホスト名 — Chuteがその接続のために解決した名前、またはsniffing-enabledが有効な場合はTLSハンドシェイク内のサーバー名 — によってのみ復号されるため、サーバー名のない素のアドレスへの接続は決して復号されません。

ホスト名エントリには、最初の/の後にパスパターンを含めることもできます。ただし復号するかどうかは、接続が開いた時点 — CONNECTを受けたとき、またはTUNセッションが始まったとき — に、リクエストパスが分かる前に決まります。そのためパス付きのエントリはホストが一致した時点で接続全体を復号し、-host/path 形式の除外はまったく効きません。あるホストを復号から外す手段としては当てにしないでください。

• example.com/api/*: ポート443でのexample.comに対するMitMを許可します。パスで範囲が絞られることはありません。

一般的な設定は次のようになります:

hostname = -*.apple.com, -*.icloud.com, *

Chuteは全てのMitMリクエスト — 最初のリクエストだけでなく、復号された接続上のすべてのリクエスト — に、URL書き換え、ヘッダー書き換え、ボディ書き換え、モックレスポンス（[Map Local]）の各ルールとスクリプトを適用します。復号したHTTP/1.1接続が運ぶのは1回のやり取りだけです。レスポンスを送り終えるとChuteは接続を閉じるため、クライアントは次のリクエストを新しい接続で送り、その接続も同じように処理されます。同じ接続で最初のリクエストの後ろにパイプライン化されたリクエストは処理されず、クライアントが新しい接続で送り直します。例外はChute AndroidがVPNから復号した接続で、開いたままその上のリクエストが順に同じように処理されます。ただし、Chuteが自分で応答したとき（モックレスポンス、URL書き換えの応答、スクリプトのresponse）や、ヘッダーだけで実行されたhttp-responseスクリプトがボディを差し替えたレスポンスを送ったときは、その後で接続が閉じられます。HTTP/2の接続は接続を維持し、WebSocketのアップグレードも同様です。101レスポンスの後は、データが両方向にそのまま流れます。

MitMはHTTP/2をサポートします。HTTPプロキシ経由でもTUN経由でも同じです。ChuteはサーバーとのTLSハンドシェイクの前に、クライアントが提示するプロトコル（ALPN）を読み取ります。クライアントがh2を提示し、[MITM]でh2 = falseとしていなければ、サーバーにはh2とhttp/1.1を提示し、そうでなければhttp/1.1だけを提示します。そのうえでクライアントにはサーバーが選んだプロトコルを提示するので、両側は常に同じプロトコルで通信します。クライアントがそのプロトコルを提示していなかった場合、ChuteはALPNを返さず、ハンドシェイクはそのまま続きます。HTTP/2では、トレーラー（gRPCのgrpc-statusなど）と103 Early Hintsのような1xxの暫定レスポンスはそのまま転送され、ルールやスクリプトからは見えません。Surgeの[MITM]キーtcp-connectionは設定ファイル内で受け付けられますが、無視されます。

一部のアプリケーションは、固定証明書やCAを使用する厳格なセキュリティポリシーを持っています。これらのホストへの復号を有効にすると問題が発生する可能性があります。

Chuteは自ら発行したホスト証明書をストアに保持し、いっぱいになると最も長く使われていないものから破棄します。macOSでは 512 枚、iOS・tvOS・Android では 128 枚です。

CA証明書のインストールと信頼

CAの生成（またはインポート）はセットアップの半分にすぎません — オペレーティングシステムがそれを信頼する必要もあります。両方のステップが完了するまで、復号される全てのサイトは証明書の警告で失敗します。アプリ内の証明書ページには現在の状態（「信頼済みCA証明書」/「未信頼CA証明書」）が表示されます。

Chute iOS — 設定エディターでMITM → CAを設定を開きます:

1. 新しいCA証明書を生成（既存の証明書を使う場合はP12証明書をインポート）。
2. CA証明書をシステムにインストールをタップします。Safariページが開くので、Install Certificateをタップしてダウンロードを許可し、設定 → 一般 → VPNとデバイス管理でダウンロードしたプロファイルをインストールします。
3. 信頼させます: 設定 → 一般 → 情報 → 証明書信頼設定で、ChuteのCAに対する完全な信頼を有効にします。このステップが最も見落とされがちです — これを行わないと証明書はインストールされただけで信頼されておらず、復号は失敗し続けます。

Chute Mac — 設定ウィンドウでMitMを開きます:

1. 新しい証明書を生成（またはPKCS#12 ファイルから証明書をインポート）。
2. 証明書をシステムにインストールをクリックします。macOSが管理者パスワードを要求し、証明書を信頼されたルートとしてシステムキーチェーンに追加します — 「キーチェーンアクセス」での手動操作は不要です。
3. 証明書をエクスポートを使うと、他のデバイスにインストールするための.pemのコピーを保存できます。

Chute Android — 設定エディターでMitM → CAを設定を開きます:

1. P12をインポートは、既存のPKCS#12をAppleのアプリと同じくbase64でca-p12に書き込むため、設定はそのCAを他のデバイスにも運べます。そのパスフレーズをCAパスフレーズに入力します。Chute Androidにジェネレーターはありません。以前のバージョンのエディターが書いていた形の、ファイルを指すca-p12も引き続き読み込まれます。
2. CAをインストールで、そのP12に含まれるCA証明書をAndroidの証明書インストーラに渡します。Android 11以降では、アプリがこの方法でCA証明書をインストールすることはできません。代わりに、システムのセキュリティ設定から証明書ファイルでインストールしてください — Chute Macの証明書をエクスポートが保存するものなど、その.pemまたは.crt形式のコピーを使います。
3. Androidはそれをユーザーの証明書として保持し、Android 7.0以降を対象とするアプリは、自らオプトインした場合にしかそれらを信頼しません。そのため、証明書をインストールした後もハンドシェイクに失敗するアプリが多くあります — それらのホストはhostnameから除外してください。

証明書が信頼されているのに特定のアプリが失敗し続ける場合、そのアプリはおそらく独自の証明書をピン留めしています — 対抗するのではなく、-プレフィックスでそのホストをhostnameから除外してください。

オプション

skip-server-cert-verify

skip-server-cert-verify = true

MitM実行中にリモートホストの証明書を検証しません。有効にすると、Chuteは自己署名証明書や無効な証明書を含む、アップストリームサーバーから提示されたあらゆる証明書を受け入れます。開発環境では便利ですが、セキュリティは低下します。

[MITM]
enable = true
ca-p12 = MIIJtQ.........
ca-passphrase = password
skip-server-cert-verify = true
hostname = *google.com

セキュリティ注意: skip-server-cert-verifyを有効にすると、Chuteとアップストリームサーバー間のMitM接続が中間者攻撃に対して脆弱になります。信頼できるネットワークまたは開発目的でのみ有効にしてください。

hostname-disabled

hostname-disabled = *.bank.example, pay.example.com:8443

hostnameのエントリに該当していても、決して復号しないホストです。ワイルドカードはhostnameと同じように使え、:portでエントリを1つのポートに限定できます。モジュールを編集せずに、モジュールが追加したホストを外したいときに便利です。

auto-quic-block

auto-quic-block = true

復号対象になるすべてのホストへのQUICをブロックし、HTTP/3クライアントをTCP上のTLSにフォールバックさせて、MitMがトラフィックを見られるようにします。block-quicの代わりではなく、それに加えて働きます。