証明書ピンニングが
証明書をピンニングしているアプリは Busymate DevTools では復号できません。iOS でも Android でもプロキシ経由でも同じです。各キャプチャ経路が何を見られて何を見られないのか、ピンニングされたホストの見分け方、それでも役に立つものを正確に説明します。
HTTPS を復号するキャプチャツールはどれも同じ仕組みです。自分で署名した証明書をクライアントに提示し、クライアントは署名した認証局を信頼しているのでそれを受け入れます。証明書ピンニングとは、アプリが特定の証明書や鍵だけを信頼し、それ以外は一切信頼しないと宣言することです。ピンニングされたアプリは代替の証明書に出会うと、単に接続を拒否します。これはツールのスイッチではなくアプリの性質であり、Busymate が提供するどのキャプチャ経路もそれを覆すことはありません。
このことを黙っているツールは、そもそも復号できるはずのなかった対象に調査セッションを浪費させます。だからこのガイドは回避策ではなく地図です。ピンニングされたホストに対して、iPhone の端末上キャプチャ、Android アプリ、デスクトッププロキシ、root 済みのファーム端末、Chrome コネクタがそれぞれ何を提供し、フィードがそれをどう表示し、それでも片付く作業は何かをまとめます。
必要な
このガイドは、少なくとも 1 つのキャプチャ経路からすでに通信がダッシュボードに届いていることを前提にしています。
すでにペアリングされキャプチャ中のスマートフォンかクライアント。iPhone または Android のガイドでそこまで到達できます。
調査対象アプリのホスト名。少なくとも復号が試みられるよう、SSL プロキシリストに追加しておきます。
ダッシュボードのフィードを開き、検査フィルターを手元に。
アプリを検査する権限。これらの手法は、自分が所有するか、デバッグを許可されたアプリやサイトの通信のためのものです。
順番どおりに
経路を順番にたどってください。それぞれが、ピンニングされたホストからまだ得られる情報を絞り込んでいきます。
- 01
自分のキャプチャ経路がどの信頼ストアに依存しているかを知る
iOS では、復号は Busymate プロファイルがインストールされ「設定」で完全に信頼されていることに依存します。その後はスマートフォン上のすべてのアプリがアプリの提示する証明書を信頼しますが、ピンニングするアプリだけは例外です。Android には 2 つのストアがあります。Android 7.0 以降は明示的にオプトインしたアプリしか尊重しないユーザーストアと、すべてのアプリが尊重するものの root 済み端末でしか書き込めないシステムストアです。デスクトッププロキシは、クライアント側のマシンやブラウザが生成された認証局に置いている信頼を利用します。
ピンニングは 3 つすべての上位にあります。ピンニングするアプリは、どのストア由来であれ代替証明書を拒否するため、証明書をより強いストアに移してもピンニングされたホストには決して効きません。効くのは、ユーザーストアを拒否していたアプリに対してだけです。
- 02
フィードでピンニングされたホストを見分ける
復号対象にリストしていないホストは、ホスト名とリクエスト数だけの閉じた錠前で表示されます。これは仕様であってピンニングではありません。ピンニングされたホストは見え方が違います。リストに入っていて、復号が試みられ、接続が失敗したか、アプリが再試行してあきらめています。ダッシュボードのフィードの検査フィルターには「復号済みのみ」「暗号化のみ」「SSL ピンニングのみ」の 3 つの設定があり、最後のものがまさにこれらの行を抽出します。
もう一つの手がかりは挙動です。そのホストが復号された途端にアプリが動かなくなり、リストから外した途端にまた動き出す。両方が当てはまれば、ピンニングされた接続を見つけたことになります。
- 03
iPhone の端末上キャプチャ：メタデータのみ、ボディは決して
iOS アプリは Wi-Fi でもモバイル回線でもシステム全体をキャプチャし、リストしたホストを復号します。ピンニングされたアプリに対しても、すべての接続を記録します。ホスト、タイミング、リクエストの数とサイズ、有効な接続モード。しかしヘッダーやボディは生成できず、それを変えるスイッチはありません。MITM All Hosts をオンにすると、ピンニングされていないホストはすべて復号されますが、ピンニングされたホストは壊れるだけです。
現実的な対処は、ピンニングされたホストをリストから外してアプリを動き続けさせ、アプリの他のホストはリストに残し、ピンニングされていないエンドポイントが明かすものを読むことです。多くのアプリは認証や決済のホストだけをピンニングし、残りは開けたままにしています。
- 04
Android：root なし、root あり、そしてピンニングの位置
root なしの Android では、アプリが生成した証明書はユーザーストアにあるため、復号できるのは自分のデバッグビルドとオプトインした他のクライアントだけで、それ以外のアプリはメタデータとして記録されます。root 済みの端末では証明書をシステムストアにインストールでき、HTTPS はシステム全体で復号可能になります。アプリごとのピンニングを除いて、です。スマホファームが Android 端末をこの root 済みの階層で運用しているのは、まさにこのためです。
つまり root は、単にユーザーストアを無視していただけの不透明なアプリの一群を読めるようにし、ピンニングされた一群には手を付けません。Busymate は root なしの端末でシステム全体の復号をうたうことも、root 済みの端末でピンニングを打ち破ったとうたうこともありません。
- 05
プロキシ：同じ限界に加えて、あえて拒否するホスト
デスクトッププロキシとピンニングの関係はスマートフォンアプリと同じで、ピンニングされたクライアントは生成された証明書を拒否し、接続は失敗します。加えて、SSL プロキシの設定にかかわらず決して傍受しないホストの短いリストを持っています。Apple 自身の PKI と失効エンドポイント、Apple の証明書チェーンが使う証明書ステータス応答サーバー、そして Busymate 自身のバックエンドです。傍受すると端末やダッシュボード自身のライブ接続が壊れるためで、これらは生のトンネルとして通過します。意図的なものであり、設定ミスではありません。
プロキシが設計上そのまま通すホスト text# Passed through as raw tunnels by the proxy, regardless of your SSL-proxy list: pkis.apple.com ocsp*.apple.com crl*.apple.com valid.apple.com ppq.apple.com # the DigiCert OCSP / CRL responders Apple's chain uses *.busymate.net # the dashboard's own backend + Realtime connection - 06
Chrome コネクタ：ピンニングは関係ない
ピンニングが無関係なキャプチャ経路が 1 つあります。コマンドラインのコネクタは Chrome インスタンスを起動し、TLS のブラウザ側で DevTools Protocol を通じて通信を読みます。Chrome とサーバー間の暗号化された接続には一切触れません。拒否すべき代替証明書もなく、インストールするものもなく、ピンニングが検知するものもありません。プロキシでは開けないピンニング済み証明書を持つプロバイダーのログインフローも、リダイレクトやトークンを含めて端から端まで記録されます。
代償は範囲です。カバーするのはその Chrome の中で動くものであって、ネイティブアプリではありません。気になるフローに Web 版があるなら、それを丸ごと見られるのがこの経路です。
- 07
ピンニングされたホストがそれでも与えてくれるものを使う
メタデータは無価値ではありません。アプリがピンニングされたホストといつ、どれくらいの頻度で通信し、やり取りの大きさと所要時間がどうかは見えますし、周囲の復号済みの呼び出しと突き合わせることもできます。ブロックルールは暗号化されたホストでもホスト単位では一致します。パスは見えませんが、そのエンドポイントに到達できないかのようにアプリを振る舞わせることができ、それはまさにテストしたかった失敗モードであることが多いのです。一時停止を使えばそのホストにプロキシを完全に迂回させ、他のすべてを検査している間もアプリを動かし続けられます。
そして行った操作はすべて監査証跡に残るので、調査セッションは何を復号し、何をブロックし、何に触れなかったかの記録を残します。
うまくいかない
いちばん時間を奪うのは、ツールのバグに見えて実はそうではないミスです。
ホストを追加した途端にアプリが壊れた
それがピンニングです。ホストを SSL プロキシリストから外し（iOS ではその後 VPN を再起動してトンネルに変更を反映させます）、アプリは復帰します。他のホストはリストに残してください。
MITM All Hosts でもアプリが開かなかった
そもそも開くはずがありません。このスイッチはピンニングされていないどのホストを復号するかを広げるだけで、アプリがピンニングしているホストには効かず、スマートフォン上の他のピンニングされた接続まで失敗させます。オフに戻してください。
Android を root 化しても解決しなかった
root は証明書をシステムストアへ移し、ユーザーストアを無視していたアプリを納得させます。証明書を自分のピンと照合するアプリには影響しません。
Apple のシステムホストがプロキシで一度も復号されない
復号すると端末が壊れるため、プロキシの傍受しないリストに入っています。直すものはなく、フィルターは設計どおり暗号化として表示します。
よくある
Busymate はピンニングのバイパスを提供していますか？
いいえ。どのキャプチャ経路も対象アプリを改変せず、コードを注入せず、信頼ロジックにパッチも当てません。ピンニングされたネイティブアプリに対する正直な答えは、メタデータと、ピンニングされていないホストが明かす情報です。
ピンニングと、単にリストに入れ忘れたホストをどう見分けますか？
リストにないホストは閉じた錠前を表示し、アプリは動き続けます。ピンニングされたホストはリストに入っていて、復号が試みられ、フィードの SSL ピンニングフィルターで抽出でき、リストから外すまでアプリは失敗します。
ピンニングされたプロバイダーの認証フローには、どの経路を選べばいいですか？
プロバイダーに Web サインインがあるなら Chrome コネクタで実行してください。TLS はブラウザ内で終端し、リダイレクトの連鎖全体が記録されます。ネイティブアプリには復号された経路がありません。メタデータと周囲のピンニングされていない呼び出しをキャプチャしてください。