ピン留めとは何ですか。証明書のピン留めについて読みましたが、その使用例に感謝しました。しかし、今日私は固定が2つのタイプになり得ることを学びました-
それぞれのユースケースについて教えてください。どちらか一方を優先する典型的なシナリオはありますか?
私の疑問の1つは、公開鍵を固定したとしましょう。私たちの接続はMitM攻撃に対して脆弱ですか?クライアントで使用される証明書と同じ公開鍵を持つCA認定ルート証明書はありますか?
2つをよりよく理解するために役立つ2つの違いはありがたいです。
これは、実際にアプリケーション/サイトが証明書と公開鍵を管理する方法、つまり、鍵と証明書がローテーションされる頻度に依存します。たとえば、サイトで証明書を頻繁にローテーションする場合、証明書を固定している場合は、アプリケーションも頻繁に更新する必要があります。一方、この使用例では、証明書に関連付けられた公開鍵は静的なままであるため、公開鍵を固定する方が良いでしょう。
質問で述べたOWASPリンクから:
証明書
証明書はピン留めするのが最も簡単です。 Webサイトの帯域外の証明書を取得し、IT担当者に会社の証明書をメールで送信し、openssl s_clientを使用して証明書を取得するなどできます。証明書の有効期限が切れたら、アプリケーションを更新します。アプリケーションにバグやセキュリティ欠陥がないと仮定すると、アプリケーションは1〜2年ごとに更新されます。実行時に、コールバックでWebサイトまたはサーバーの証明書を取得します。コールバック内で、取得した証明書をプログラム内に埋め込まれた証明書と比較します。比較が失敗した場合、メソッドまたは関数も失敗します。
証明書をピン留めすることには欠点があります。サイトが定期的に証明書をローテーションする場合は、アプリケーションを定期的に更新する必要があります。たとえば、Googleは証明書をローテーションするため、月に1回程度アプリケーションを更新する必要があります(Googleサービスに依存している場合)。 Googleが証明書をローテーションしても、(証明書内の)基盤となる公開鍵は静的なままです。
公開キー
公開鍵のピン留めはより柔軟ですが、証明書から公開鍵を抽出するために必要な追加の手順のため、少しトリッキーです。証明書の場合と同様に、プログラムは抽出された公開鍵と埋め込まれた公開鍵のコピーをチェックします。公開鍵の固定には2つの欠点があります。まず、通常は証明書からキーを抽出する必要があるため、(証明書ではなく)キーを扱うのは困難です。抽出は、Javaと.Netでは多少不便ですが、Cocoa/CocoaTouchとOpenSSLでは不快です。次に、キーは静的であり、キーローテーションポリシーに違反する可能性があります。
MitMに関しては、証明書のピン留めを正しく実装していれば、TLS接続はMitM攻撃に対して脆弱ではありません。攻撃者が、アプリケーションが固定した同じ公開キーで自分のドメインの有効な証明書を取得できたとしても(ルージュCAを通じて) )、対応する秘密鍵はまだありません。したがって、アプリケーションとの有効なTLS接続を作成できません(TLSハンドシェイク自体を実行できないため)。
証明書のピン留めの大きな問題は、証明書の保存期間が限られており、費用がかかることが多いことです。からの無料の証明書では、過去90日間しか暗号化できません。お金を払えば、最近CA /ブラウザフォーラムで設定されている制限である2年強を手に入れることができます。これは将来さらに削減されない保証はありません。
証明書は、購入するまで固定できません。購入すると、使用するかどうかにかかわらず、ライフタイムが刻々と過ぎていきます。したがって、証明書をピン留めすると、多くの追加の証明書を購入することになり、古いバージョンのコードを使用して接続しようとするユーザーに問題が発生する可能性があります。
一方、公開鍵には有効期間の制限はありません。キーの固定を使用する場合は、キーペアを生成できます。秘密キーをボールトに配置し、公開キーをアプリに配置します。その後、数年後、ボールトから秘密鍵を取り出し、証明書を取得してサービスに使用できます。
キーの固定の潜在的な欠点は、キーの失効がないことです。キーが危険にさらされている場合、証明書を取り消すことができますが、友好的なCAを持つ攻撃者は、盗まれたキーを使用して新しい証明書を取得する可能性があります。 OTOH証明書の失効は、一般に非常に脆弱です。
私の2セントの一部:
証明書が更新された場合にアプリケーションを更新するのが難しいシナリオ(たとえば、組み込みシステムやIoTアプリケーション)で、公開キーのピン留めが使用されると想像できます。それ以外の場合は、証明書のピン留めの方が便利です。
公開鍵が十分なエントロピーで生成される場合、同じ2つの鍵が存在する可能性は低くなります。