SSLピン留めと証明書の有効期限
この質問は、WebAPIおよび証明書の有効期限に対するクライアントアプリでのSSLピンニングの使用に関連しています。
シナリオ：
私はexample.comを所有しており、apiがホストされているサブドメインを持っています、そのようなもの：api.example.com
API over[〜＃〜] ssl [〜＃〜]を使用したいので、サブドメイン用にSSL証明書が作成されます。
証明書を取得した後、私は次のことを行います。
- 公開証明書
- 中間証明書
- 秘密鍵
これらの証明書をWebサーバーにインストールすることは私の理解です。
次に、クライアントアプリがAPIに接続することを望みます。 man-in-the-middleスタイルの攻撃を軽減するために、SSLピンニングを使用して、クライアントが私のapiとのみ通信し、誰かがそれをスプーフィングしないようにします。
クライアントアプリにピン留めするには、公開証明書または中間証明書に対してピン留めするという2つの選択肢があります。
これを実装するとしましょう。
api.example.comの証明書の有効期限が切れるとどうなりますか？
クライアントアプリが機能しなくなることは私の理解です。
パブリック/中間/プライベートアイテムの完全なセットを再生成する必要がありますか？次に、アプリに新しい公開証明書または中間証明書を配置しますか？
質問：
Api.example.comの証明書が更新されるまで、クライアントアプリを機能させたいのですが。もちろん、新しい証明書をクライアントアプリに配置することもできますが、ロールアウトなどには時間がかかります。
どうすればこれを処理できますか？
Googleが毎月証明書を更新していることを読みましたが、どういうわけか公開鍵を同じに保つことができます： iOSで証明書の公開鍵を固定する方法
それが可能であれば、解決策はサーバーから公開鍵を抽出し、ローカルに保存されている公開鍵と照合することです...しかし、Googleはどのようにそれを行いますか？
ありがとう
クリス
注：私はアプリからサーバーへのピン留めよりもブラウザーからサーバーへのピンニング（HTTP公開鍵ピンニング-HPKP）に精通していますが、プリンシパルは同じだと思います。 HPKPでは、ピン留めポリシーはサーバーによってHTTPヘッダーとして提供されますが、これはHTTP応答から読み取られるのではなく、アプリに組み込まれていることが多いことを理解してください。したがって、以下の回答をすべて念頭に置いて読んでください。
固定は通常、証明書ではなくキーに対して行われ、複数のレベルになる可能性があります。したがって、いくつかの選択肢があります。
同じキー/ crtを再利用して、新しい証明書を生成します。一部の人（私の意見では当然です！）は、証明書を更新するたびに新しいキーを生成することを推奨していますが、ピン留めを使用する場合、これは複雑です。では、ピン留めは、キーの再利用などの不十分なセキュリティ習慣を助長しますか？
固定ポリシーにいくつかのバックアップキーを用意し、証明書の更新時にそれらをローテーションして、最も古いものを破棄し、十分な時間と更新を加えて新しいキーを追加します。個人的には、侵害された可能性のあるバックアップを作成するよりも、証明書の更新時にキーを生成する方が好きなので、これも特に好きではありません。そして、いくつのバックアップが必要ですか？例えば。更新に関する妥協のために証明書を再発行する必要があり、それを台無しにする必要がある場合はどうなりますか？だから2？ 3？ 100？
さらに上に固定します。最初の中間CA証明書またはルートCA証明書を言います。したがって、新しく発行された証明書は引き続き信頼されます（同じ証明書パスによって発行された場合）これの欠点は4つあります：i）ピン留めされた証明書によって発行された未発行の証明書を受け入れることができます（大規模な取引ではありません攻撃対象領域は大幅に削減されましたが、一部の人にとっては懸念事項です）、ii）有効なパスが複数ある場合があるため、クライアントがその中間証明書を使用することを保証できません。この2つ目は、はるかに大きな取引です。中間証明書を提供することで、これが使用されることが保証されると思うかもしれませんが、そうではありません（sha-1の例がたくさんあります）。 iii）新しい証明書が同じ中間体またはルートによって発行される保証はありません（特にsha2の導入のようにテクノロジーが変更された場合）ので、私にとってこのオプション全体は初心者ではありませんiv）同じ証明書プロバイダーを使用することに結びつきます（おそらく大したことではありませんが、私は動く自由が好きです）。とにかくアプリがこの機能をネイティブにサポートしているかどうかはわかりませんが、ブラウザーは確かにサポートしています。
事前に更新し、ポリシーキャッシュの有効期限が切れるまで新しいキーを使用しないでください。たとえば、1年間の証明書と30日間の固定ポリシーがある場合、11か月後に更新し、新しいキーをポリシーに追加してから30日間待つと、全員が新しいポリシーを取得するか、少なくとも古いポリシーは期限切れになり、キーと証明書を切り替えます。短いポリシーに依存し、古いポリシーの有効期限が切れた翌日から証明書プロバイダーが事前に証明書を提供しない限り、その一部（この例では少なくとも30日）を無駄にする可能性があります。アプリの場合、ピン留めポリシーがアプリにハードコードされていると、更新をプッシュするのにかかる時間が長くなる可能性があります。
最終的に、証明書は更新する必要があるため、私はピン留めの大ファンではありません。 is定期的に更新されるようなものを作ることは、正解ではないと思います。また、ブラウザにピン留めポリシーをプリロードするという話もありますが、それは私を震え上がらせます。
ピン留めは、不正なCAがドメインの証明書を発行していないことを保証しますが、ピン留めの煩わしさと比較して、実際にどの程度の可能性がありますか？証明書の透明性のようなもの、またはピン留めのみを報告することでさえ、実際にその攻撃を止めなくても、その問題に対するより良い答えかもしれません。
最後にローカルにインストールされたルート（ウイルス対策スキャナーや企業プロキシなど）は、ピン留めチェックをバイパスします（少なくともブラウザーでは）。これも私の目にはその効果を低下させます。
したがって、ピン留めを使用する前に慎重に検討し、すべての結果を理解していることを確認してください。
mozilla開発者サイト サーバー証明書に署名した中間CAの証明書を固定することをお勧めします。
「証明書の更新とローテーションを容易にするために、サーバー証明書を発行したCAの中間証明書にピンを配置することをお勧めします。」
公開鍵ピンニングの実装とテストの詳細については、 HTTP公開鍵ピンニング（HPKP）の実装とテスト を参照してください。