TLSピン留めとVPNの入場は別の問いに答える

私用のモバイルアプリをVPNの背後に置くと、まともな人なら、まだ証明書ピン留めが必要なのかと尋ねるでしょう。その問いは、同等の二つの制御のどちらかを選ぶ話のように聞こえますが、実際には二つの異なる門についての問いです。VPNはこの端末がその経路を使えるかどうかを決め、アプリは到達したサーバーが期待したものであるかを決めます。両方を別々に答えれば、設計はもっと単純になります。

二つの門、二つの問い

ネットワークへの入場はクライアントの話です：この端末は登録されているか、その資格情報は有効か、ポリシーはこの経路を通すか。アプリの信頼はサーバーの話です：接続はアプリが受け入れる身元を持つサービスに届いたか。これらの答えは別々のシステムから来て、別々の理由で失敗し、別々のチームが直します。VPNのハンドシェイクが成功しても、アプリは相手の背後にある期限切れの証明書と話しているかもしれません。完全にピン留めされたアプリでも、端末がネットワークに入れなければ誰からも届きません。

両者は足し算の関係にあります。 一方を落とせば制御が一つ減り、他方を足しても置き換えにはなりません。

ピン留めが実際に制限するもの

ピン留めは、アプリが受け入れるサーバー身元の集合を狭め、通常は、ストアが保証するあらゆる連鎖を信頼するのではなく、公開鍵や証明書のハッシュを名指しします。これは通常の検証の上に重ねる制約であり、その代替ではありません。通常の検証は連鎖がそもそも信頼できるかを答え、ピン留めはそれがこのアプリの期待する連鎖かを答えます。最初の段階を飛ばす実装は、安全性ではなく目新しさを得ただけです。

ピン留めする対象はプラットフォームによって異なるので、その言葉だけではほとんど何も分かりません。ある製品のトラストストアからハッシュをコピーし、モバイルアプリでも同じものとして扱うのは、よくある静かな誤りです。

プラットフォーム上のピン留めは設定であり、ポリシーではありません

Androidはネットワークセキュリティ設定を通じてピン留めを公開し、ピン集合は公開鍵のダイジェストを保持し、連鎖はその少なくとも一つを含む必要があります。このファイルはアプリごとにあり、意図的なビルド変更を要します。iOSには同等のマニフェスト機構がないため、そこでのピン留めはアプリ自身の信頼評価コードの中に住みます。

機構が異なるため、要件はプラットフォームごとに書く必要があります。プラットフォームを名指しせずに証明書をピン留めせよと言うポリシーは、実装できません。

ローテーションがピン留めの生死を決める

難しいのは最初のリリースではなく、その後の証明書更新です。厳格な信頼ポリシーは、正規の新しい鍵も攻撃者の鍵と同じ強さで拒否します。

ローテーションを耐えられるものにする機構は二つあります：必要になる前にすでに信頼されている予備のピンと、ピン集合に有効期限を設けて、アプリを止めるのではなく強制を失効させることです。どちらもポリシーの判断であり、とりわけ有効期限は無害なタイマーではなく、意図的な安全性の引き下げです。アプリのビルド、TLSの端点、証明書更新を誰が管理するかを名指しし、それらを一つの変更プロセスにまとめてください。それが三つの別チームなら、ピン留めはいずれ、誰も予定していなかった障害を起こします。

紛失した端末は第三の問題です

VPNの資格情報を取り消しても、アプリのセッションが必ず終わるわけではなく、サーバーのピン留めは他人の手にある電話に対して何もしません。端末のロック、資格情報の保存、セッションの寿命、遠隔からの取り消しは、それぞれ別の所有者を持つ別の判断です。これらをピン留めの議論に折り込めば、どれも設計されないことが保証されます。

目に見える一つの関係ではなく、四つの関係を試してください：意図したサーバーと操作、拒否されるべきアカウント、拒否されるべきサーバー身元、そして計画されたローテーションです。動くVPNが試すのは最初の一つだけです。各試験が何を証明したかを書き留めてください、次の人は、緑のトンネルが四つすべて合格を意味すると考えるからです。