中間者攻撃と証明書ピンニングの原理

MITM が成立する条件：経路の支配では足りない

中間者攻撃（Man-in-the-Middle, MITM）は、通信の経路に攻撃者が割り込み、双方になりすまして読み書きする攻撃です。平文通信なら経路を握るだけで成立しますが、TLS で守られた通信に対しては、経路の支配だけでは破れません。決定的なのは信頼の根を握れるかどうかです。

TLS のサーバー認証は、サーバーが提示する証明書を、クライアントが自分のトラストストア（信頼する CA の一覧）に照らして検証する仕組みです（詳細はX.509 チェーン検証）。攻撃者がサーバーになりすますには、接続先ホスト名に一致し、かつクライアントが信頼する CA の署名が付いた証明書が必要です。攻撃者が自前で偽証明書を作っても、署名する CA がトラストストアに入っていなければ、検証は「信頼できない発行者」で失敗します。

つまり TLS に対する MITM の成立条件は、次のいずれかを攻撃者が満たすことに集約されます。

逆に言えば、CA の鍵もトラストストアも握れず、クライアントの検証が正しければ、攻撃者は経路を完全に支配していても TLS のコンテンツを読めません。MITM 対策の議論が「暗号の強度」ではなく「誰がトラストストアを支配しているか」に帰着するのはこのためです。

企業/検閲プロキシによる TLS 傍受の仕組み

実務で最も多く目にする「正規の MITM」が、企業の TLS インスペクションプロキシです。攻撃ではなく管理目的ですが、技術的には MITM そのものです。流れはこうです。

端末 ──TLS①──> プロキシ ──TLS②──> 本当のサーバー(example.com)

1. 管理者が独自ルート CA を全端末のトラストストアに事前配布(MDM/GPO)
2. 端末が example.com へ接続を開始
3. プロキシが接続を横取りし、本当のサーバーへ TLS② を自分で張る
4. プロキシが「example.com」の偽証明書をその場で生成し、
   手順1のルート CA で署名して端末へ提示 → TLS① が成立
5. プロキシは TLS① と TLS② の平文を中継しつつ全文を可視化

鍵は手順1です。端末のトラストストアに管理者のルート CA を入れた瞬間、プロキシは任意のホスト名の証明書を「正規に」発行できるようになります。端末から見ると証明書チェーンは完全に正しく検証を通るため、ブラウザの鍵マークも正常に表示されます。検閲を行う一部の国家も、国民の端末に国家発行ルート CA の導入を求めることで、同じ原理で大規模に TLS を傍受します。

証明書ピンニング：信頼を CA から特定の鍵へ絞る

トラストストアを攻撃者（や管理者）に書き換えられると MITM が通ってしまう——この弱点の根は、「信頼する CA なら誰が発行した証明書でも受け入れる」という PKI の寛容さにあります（PKI の信頼モデル）。公開 CA は数百あり、そのどれか一つでも侵害・誤発行・強制されれば、任意のドメインの偽証明書が作られうる。これを CA の代替可能性（any-CA problem） と呼びます。

証明書ピンニング（pinning）は、この寛容さを意図的に殺す対策です。「この接続先は、この特定の証明書／公開鍵でなければ受け入れない」とクライアント側にあらかじめ焼き込み、チェーン検証に通ってもピンと一致しなければ拒否します。攻撃者が別の（しかし正規に信頼される）CA で偽証明書を作っても、その鍵はピンと違うため弾かれます。

ピンする対象によって二系統あります。

実務では公開鍵ピンニングが優勢です。固定するのは SubjectPublicKeyInfo（SPKI）の SHA-256 ハッシュで、証明書の有効期間が切れても、同じ鍵ペアで再発行すればピンは変わりません。固定する層も選べます。リーフ（サーバー）の鍵をピンすると最も厳格ですが更新が頻繁になり、中間 CA の鍵をピンすると「その中間 CA が出す証明書なら許す」と緩めつつ、公開 CA 全体を信頼するよりは攻撃面を絞れます。

公開鍵ピンの作り方（概念）
pin = base64( SHA-256( DER(SubjectPublicKeyInfo) ) )

クライアントは接続時、提示された証明書チェーンの各証明書から
SPKI を取り出してハッシュし、保持するピン集合のいずれかに
一致すれば許可、全滅なら拒否する。

ピン失敗ブリック：運用リスクの正体

ピンニングは強力ですが、その厳格さがそのまま運用リスクになります。最悪のシナリオがピン失敗ブリックです。何らかの理由で本番の鍵がピンと一致しなくなると、クライアントは正規のサーバーにすら接続できなくなり、アプリが一斉に通信不能（ブリック）に陥ります。配布済みのモバイルアプリにハードコードされたピンは、サーバー側をいくら直しても、アプリを更新して全ユーザーが入れ替えるまで回復しません。

ブリックを誘発する典型は次の通りです。

唯一にして必須の防御策がバックアップピンです。本番鍵とは別に、まだ使っていない予備の鍵ペア（できれば独立した CSR から生成し、オフラインで安全に保管）を用意し、その SPKI ハッシュもピン集合に入れておきます。本番鍵が使えなくなったら、バックアップ鍵で証明書を再発行して切り替えれば、既存クライアントはバックアップピンとの一致で接続を維持できます。バックアップピンのない単一ピンは、鍵漏洩時に「漏洩を放置するか、自分でアプリをブリックさせるか」の二択を迫る、運用上ほぼ禁じ手の構成です。

なお、ピンニングはトラストストアより優先されるため、前節の企業傍受プロキシを意図的にブロックします。利点である一方、正規の企業環境で使えなくなる副作用でもあり、業務アプリでは「管理端末のプロキシは許容する」例外設計が必要になることもあります。ピンは「強さ」と「運用の硬直」のトレードオフだと理解するのが要点です。

HPKP の廃止と Expect-CT、そして現在

ブラウザ（Web）にピンニングを持ち込もうとした標準が HPKP（HTTP Public Key Pinning, RFC 7469） でした。サーバーが Public-Key-Pins レスポンスヘッダで SPKI ハッシュと max-age を宣言し、ブラウザがそれを記憶して以後の接続で照合する TOFU（Trust On First Use） 方式です。

HPKP は理屈は正しかったものの、二つの致命的な問題で主要ブラウザから廃止されました。

• 自爆（ホステージ）リスク: サーバー運用者が設定を誤る、または鍵を失うと、max-age の間ブラウザがそのサイトを拒否し続け、サイト側で即座に回復できません。バックアップピンの管理を全 Web サイト運用者に正しく強いるのは非現実的でした。
• ランサム・ピン（RansomPKP）攻撃: サーバーを一時的に乗っ取った攻撃者が、自分の鍵で長い max-age の HPKP を送り込むと、正規運用者が復旧しても、その期間ユーザーは攻撃者の鍵以外を信頼できなくなり、サイトが人質に取られます。

代替として一時的に使われたのが Expect-CT ヘッダです。これはピンニングとは目的が異なり、「この接続ではCertificate Transparency の SCT を必須とし、なければ報告／拒否せよ」とブラウザに要求するものでした。誤発行された証明書は CT ログに載れば検知できるという前提に立ち、any-CA 問題を「鍵の固定」ではなく「全発行証明書の公開監査」で抑える発想です。

結果として、Web ではピンニングは事実上消え、誤発行対策は CT による事後検知へ、傍受対策はトラストストア管理と HSTS（セキュリティヘッダ）へと役割分担が移りました。一方、トラストストアを自分で管理しないモバイルアプリやネイティブクライアントでは、CA への依存を断ち切る手段として、SPKI ベースの公開鍵ピンニング（OS が提供する Network Security Config や App Transport Security 等）が今も有効な選択肢として残っています。Web とアプリで結論が分かれるのは、「誰がトラストストアと回復手段を握るか」が違うからです。

まとめ

TLS に対する MITM の成立条件は、攻撃者がクライアントのトラストストアが信頼する CA の署名で偽証明書を作れることに尽きます。経路支配だけでは破れず、CA 鍵の侵害・トラストストアへの書き込み・クライアントの検証不備のいずれかが要ります。企業/検閲プロキシは独自ルート CA を端末に配ることでこの条件を満たし、端末との TLS とサーバーとの TLS を別々に張って平文を中継します。

証明書/公開鍵ピンニングは、信頼を CA から特定の鍵へ絞り、CA の代替可能性問題を閉じます。実務では SPKI ベースの公開鍵ピンが主流ですが、その厳格さはピン失敗ブリックという運用リスクと表裏一体で、独立したバックアップピンが必須です。Web では HPKP が自爆リスクと RansomPKP 攻撃で廃止され、Expect-CT も CT 必須化で役目を終え、ピンニングはモバイル/ネイティブの領域へ退きました。土台となるPKI、X.509 チェーン検証、mTLS と併せて読むと、TLS の信頼が「鍵をどこに固定し、誰がトラストストアを握るか」で決まることが原理から見えてきます。