Fiddler のインストールと HTTPS リクエストのキャプチャ
ご存じのとおり Fiddler は非常に実用的なパケットキャプチャツール（主に HTTP リクエスト向け）で、公式サイトからダウンロードできる拡張機能も豊富です。開発の中では、インターフェースのデータを確認したり、API の安全性をテストしたり（署名なしで値を改変できるかどうかなど）するために、キャプチャツールが必要になる場面は避けられません。ここでは Fiddler のインストールと、証明書を設定して HTTPS の暗号化された情報をキャプチャする方法を紹介します。
API 開発をしていると、最もよくある要望は「リクエストは本当に送信されたのか、パラメータは正しいのか、サーバーは何を返したのか」を知りたいというものです。ブラウザの F12 ではブラウザ自身が送ったリクエストしか見えず、アプリ、デスクトッププログラム、バックエンドサービス間の呼び出しは見えません。一方ログにはたいてい業務フィールドしか記録されておらず、本当に確認したい生のメッセージが抜けています。キャプチャツールはまさにこの隙間を埋めるものです。プロキシとしてクライアントとサーバーの間に座り、すべてのリクエストとレスポンスを丸ごとあなたの前に並べてくれます。Fiddler はこの種のツールの中で、設定コストが最も低く、HTTP のサポートが最も扱いやすいものの一つです。
厄介なのは HTTPS です。今どきの API は基本的に HTTPS で、メッセージは全経路で暗号化されているため、プロキシがトラフィックを捕まえても、そこにあるのは暗号文の山だけです。平文を見るには、Fiddler に「中間者（マン・イン・ザ・ミドル）」として TLS ハンドシェイクに介入させる必要があります。これが本記事でしっかり説明したい部分です。
ダウンロードとインストール
Fiddler の公式サイト：
Fiddler | Web Debugging Proxy and Troubleshooting Solutions
対応するバージョンを選んでダウンロードします。個人のデバッグ用途なら無料の Fiddler Classic で十分で、エンタープライズ版の登録は不要です。
インストールが完了したら起動します：
この時点で、何も設定しなくてもすでに HTTP リクエストを直接キャプチャできます（HTTP は平文で転送されるためです。もちろんリクエストがシステムプロキシを経由する必要はあり、Firefox ブラウザは「手動でプロキシを設定」する必要があります）。しかしプロジェクトで HTTPS リクエストを使っている場合、HTTPS リクエストの安全性によりすべてのデータが暗号化されています。では、どうやってその中の情報をキャプチャすればよいのでしょうか？
ここでプロキシの仕組みを補足しておきます。Fiddler は起動時に自身をシステムプロキシとして登録し、デフォルトで 127.0.0.1:8888 をリッスンします。システムプロキシを経由するプログラム（ほとんどの Windows アプリ、Chrome、Edge）は、自動的にトラフィックを Fiddler へ転送します。一方 Firefox は独自のプロキシ設定を持っており、システムプロキシに従わないため、ネットワーク設定で「手動でプロキシを設定」し、同じアドレスとポートを指定する必要があります：
HTTP 代理: 127.0.0.1
端口: 8888
HTTPS キャプチャの原理
まず Fiddler の証明書を設定する必要があります。なぜこんなものを設定するのか？と疑問に思う人もいるでしょう。まずは簡単に原理を見てみましょう：
1、Fiddler が私たち自身のクライアントの HTTPS リクエストを傍受します。
2、傍受したリクエストをリクエスト先のサーバーへ転送します。
3、リクエスト先のサーバーが応答し、証明書ファイルを生成して私たちのクライアントへ送ります。Fiddler がこれを傍受し、サーバーが応答した証明書ファイルを取得したうえで、私たちが設定した偽造証明書を私たち自身のクライアントへ送ります。
4、クライアントは偽造証明書を受け取り、再度データをリクエストします。データはすでに偽造証明書に基づいて暗号化されています。
5、Fiddler は傍受してその中のすべてのリクエスト情報を取得し、さらにステップ 3 で傍受した本物の証明書ファイルを使って情報を暗号化し、リクエスト先のサーバーへ送信します。
要するに、Fiddler はデータを中間で転送する役割を果たしています。だからこそ、クライアントが送信するデータとサーバーが応答するデータの情報を取得できるのです。
平たく言えば、これは一種の「善意の中間者攻撃」です。HTTPS の安全性は証明書の信頼チェーンに依存しています。クライアントはサーバー証明書を受け取ると、それが自分の信頼するルート証明機関によって発行されたものかどうかを検証します。Fiddler が証明書をすり替えてもクライアントに拒否されないのは、Fiddler のルート証明書をシステムの「信頼されたルート証明機関」にインストールしたことが前提です。一度インストールすれば、Fiddler がその場で発行する偽造証明書は検証を通過し、クライアントはそれを使って後続のデータを暗号化するようになり、平文が Fiddler の手に落ちるというわけです。これが、以下のステップ 2「ルート証明書を信頼する」が省略できない理由でもあります。
証明書の設定
Fiddler の証明書設定：
1、Tools -> Options -> HTTPS
Decrypt HTTPS traffic をクリックし、from all processes を選択します。
このステップは HTTPS 復号のメインスイッチを入れる操作です。from all processes はすべてのプロセスの HTTPS トラフィックを復号することを意味します。特定のプログラムだけキャプチャしたい場合は、from browsers only に変えるか、後述のプロセスフィルタを使うことで、無関係なトラフィックでリストが埋め尽くされるのを避けられます。
2、Actions -> Trust Root Certificate
このステップこそ、先ほど原理のところで述べた鍵となる操作です。Fiddler のルート証明書をシステムの信頼ストアにインストールします。
3、yes をクリックすると証明書の設定は完了です。キャプチャを開始すれば HTTPS リクエストの内容情報を確認できます。
ダイアログで Yes をクリックして信頼を確認すれば、証明書のインストールは完了です。メイン画面に戻ると、以前は暗号化された文字化けとして表示されていた HTTPS セッションで、平文のリクエストヘッダ、リクエストボディ、レスポンスボディが見えるようになります。
ハマりどころと注意点
- 特定のアプリのパケットがキャプチャできない：たいていはそのアプリがシステムプロキシを経由していないか、証明書検証の回避策が取られているためです。Android 7 以降、アプリはデフォルトでユーザーがインストールした証明書を信頼しません。アプリ自身の設定か別の手段が必要で、Fiddler で証明書をインストールするだけではキャプチャできません。
- クライアントが SSL Pinning（証明書ピンニング）をしている場合：この種のアプリはサーバー証明書のフィンガープリントをコードに埋め込んでおり、Fiddler がすり替えた証明書を見ると接続を直ちに拒否します。通常の設定では対処できません。
- Firefox でキャプチャできない：Firefox 独自のプロキシ設定が
127.0.0.1:8888を指しているか確認してください。このステップを忘れないように。
Fiddler のルート証明書をシステムにインストールするということは、このマシンにすべての HTTPS を復号できる穴を開けるのと同じことです。デバッグが終わったら、Tools -> Options -> HTTPS で Remove Interception Certificates をクリックするか、システムの証明書管理から DO_NOT_TRUST_FiddlerRoot を削除することを忘れずに。開発マシンに長期間残しておかないようにしましょう。
まとめ
HTTP の平文キャプチャはほぼ設定不要で、HTTPS のキャプチャの核心はたった 2 つ。Decrypt HTTPS traffic を有効にすることと、Fiddler のルート証明書を信頼することです。「中間者 + 偽造証明書」という本筋を理解していれば、パケットがキャプチャできないときも、どこで引っかかっているのか——プロキシを経由していないのか、証明書が信頼されていないのか、それとも相手が Pinning をしているのか——おおよそ判断できるようになります。
COMMENTS