ワイルドカードSSL証明書によって引き起こされる可能性のある脆弱性は何ですか？
この答え に関するコメントで、AviDは言う：
「ワイルドカードSSL証明書には多くのセキュリティ問題があります。」
それで、問題は何ですか？同じ秘密鍵が複数のコンテキストで使用されていることを理解していますが、すべてのアプリケーションを同じホスト名でホストできることを考えると、これはワイルドカード証明書によって引き起こされる「新しい」問題とは見なされません。
「ワイルドカード証明書」は、可能なサーバー名として、「_*_」文字を含む名前を含む証明書です。詳細は RFC 2818、セクション3.1 にあります。結論：サーバー証明書に_*.example.com_が含まれている場合、クライアントは clients によって見かけの名前であるサーバーの有効な証明書として受け入れられますその名前に一致します。
Webサイトの認証ビジネスには、主に4つの主体があります。
- SSLサーバー自体。
- クライアントが使用するWebブラウザーのベンダー。
- クライアントブラウザの動作をある程度制御する人間のユーザー。
- サーバーに証明書を発行したCA。
ワイルドカード証明書は、SSLサーバーの追加の脆弱性を意味するものではありません。実際、SSLサーバーは自身の証明書を調べることに関心がありません。その証明書は、証明書に含まれている公開鍵が実際に本物のSSLサーバーの公開鍵であることをクライアントに納得させるために、クライアントの利益のためのものです。 SSLサーバー知っている独自の公開/秘密鍵のペアであり、それについて確信する必要はありません。
人間のユーザーは、公開鍵が何であるかを知りません。彼が見るのは南京錠のアイコンであり、さらに重要なのは対象のサーバー名：これは "_https://_"の右側で次の "_/_ "。 Webブラウザーは想定であり、名前が正しいことの確認、つまりサーバー証明書の検証、および名前が前述の証明書に書かれている名前と一致することの確認に関する技術的な詳細を処理します。ブラウザーがこの作業を行わない場合、それはだらしのないものと見なされ、その役割を引き受けないと見なされます。同様に、CAは契約上、SSLサーバーの所有者を特定するための定義された手順に従う必要があるため、攻撃者が偽の証明書を取得するのは困難です（契約はCAとそのスーパーCAの間で再帰的に、バインドされているルートCAまで） OSまたはブラウザのベンダーとの協定により、定義された条件下でOSまたはブラウザにルートCAキーを含めることを受け入れた）。
つまり、ブラウザおよび[〜＃〜] ca [〜＃〜]は、実際には、検証プロセスを通じてユーザーを甘やかす必要があります。それらは、多かれ少なかれ、合法に見える偽のサイトを通じてユーザーが騙されることを防ぐための義務（法律またはビジネス上の考慮によりさらに厳しい）の下にあります。ユーザーのジョブとブラウザ/ CAジョブの境界は明確に定義されておらず、歴史的に変化しています。 Days of Yoreでは、つまり10年ほど前のことですが、ブラウザは未加工のURLを出力しただけで、その中のサーバー名を見つけるのは人間のユーザー次第でした。これは、技術的には有効であるが誤解を招くURLを使用するために、次のように偽造サイトオペレーター（「フィッシングサイト」）を偽造したものです。
_https://www.Paypal.com:[email protected]/confirm.html
_人間のユーザーはhumanであり、ほとんどのユーザーは左から右に読んでいるため（最もリッチで騙されやすい詐欺のターゲットは依然として西欧諸国にあります）、左側から始まります__www.Paypal.com_、コロン記号（「技術的すぎる」）で停止し、騙されます。
反応として、ブラウザーベンダーは、人間のユーザーのURL解析機能が当初想定されていたほど優れていないことを認めており、最近のブラウザーはドメイン部分を強調しています。上記の場合、これは_xcvhjvb.com_であり、_Paypal.com_が含まれるものはありません。 ワイルドカード証明書がゲームに入る部分が来ました。 _xcvhjvb.com_の所有者が「_*.xcvhjvb.com_」を含むワイルドカード証明書を購入すると、次のようなフィッシングサイトをセットアップできます。
_https://Paypal-payment-interface-login-session.xcvhjvb.com/confirm.html
_これはブラウザーで受け入れられ（ワイルドカード名と一致します）、注意を払わないユーザーをキャッチする可能性があります（そして多くのユーザーがいます...）。この名前couldはワイルドカードに頼らずに攻撃者によって購入されたものですが、CAの従業員は明らかに不正な試みでこの名前を見ました（良いCA doの人間による検証証明書のすべての要求、または少なくとも非常に長い名前、および/または既知の銀行名が含まれている名前のアラートを生成する）。
したがって、ワイルドカード証明書は、CA側の詐欺封じ込め手段の効果を低下させます。これは、CAからの空白の署名のようなものです。ワイルドカードベースのフィッシングの試みがより一般的になった場合、次の対策の1つまたは複数が出現すると予想できます。
- ブラウザは、証明書のnon-wildcard要素に一致するドメイン名の部分のみを強調表示します。
- CAは、ワイルドカード証明書の重い書類と契約を必要とします（これらはより高価になります）。
- ブラウザはワイルドカード証明書のサポートを完全に無効にします。
実際には、3つの対策すべてが数年以内に適用されることを期待しています。私はそれについて完全に間違っている可能性があります（それが未来を予測する際の問題です）が、これはまだ私の直感です。
ちなみに、ワイルドカード証明書は異なるサーバーnames間で同じキーペアを共有するのに役立ちます。これにより、秘密キーが異なるサーバー間で共有される可能性が高くなりますmachines。秘密鍵の移動は、それ自体がセキュリティリスクです。秘密鍵がさまよっているほど、「秘密」が少なくなります。
異なるサービスを提供する複数のサーバーに同じ秘密鍵を分散することは悪い習慣です。サービスで悪用されたセキュリティ問題はすべて、すべてに使用されている秘密鍵を明らかにします。
しかし、ワイルドカード証明書を使用して、ユーザーが提供したWebコンテンツをユーザー固有のサブドメインに分離し、同じOriginポリシーを利用するのが一般的です。信頼されていないポートレットを表示するには、同じアプローチが一般的に使用されます。 Open Social 「標準」の一部です。
私の職場では、オープンなソーシャル実装を含み、ワイルドカード設定を使用するソフトウェアを開発しています。お客様の設置は、侵入テストを受けています。ワイルドカードの設定は批判されませんでした。
結局のところ、これらの回答で指摘されている脆弱性の多くは、さまざまなレベルの信頼に起因しています。ただし、ワイルドカード証明書がどのように機能するかを理解していれば、特定のユースケースでこれらの脆弱性を軽減できます。これをより詳細に説明することで、この質問とその回答の有用性が向上すると思います。
ドメイン内のすべてのシステムの信頼レベルが同じでない限り、ワイルドカード証明書を使用して、制御下にあるすべてのシステムをカバーすることはお勧めできません。ただし、セグメンテーションツールとしてDNSサブドメインを使用できます。 Hendrikが言ったように、ワイルドカードはサブドメインを通過しないため、ワイルドカード証明書を特定の名前空間に制限できます。たとえば、CDNファームがある場合は、*.cdn.example.comだけをワイルドカードにすることができます。これにより、example.com自体（www.example.comなど）内のホストが分離され、www.example.comに対して別の証明書を発行できます。
AviDがOWASPから言及したように、内部ワークステーション、開発システムなどは、より低い信頼レベルに属しています。ただし、これらのようなホストは、（prv.example.comなどの）独自の内部ドメイン空間にある必要があります。ワイルドカードはサブドメインを通過しないため、*.example.com証明書をprv.example.comホストに適用することはできません。 （これにより、パブリックプロパティとプライベートプロパティが分離されますが、プライベートプロパティが互いに分離されることはありません。他のサブドメインワイルドカードを使用して、適切な信頼レベルにマップできます）。
このeWeek記事 は秘密鍵を複数のホスト間で共有できることを注記していますが、 このSSLShopperの反論 は、（DigiCertなどの）一部の発行者がそれぞれに個別の秘密鍵を生成できることを示していますワイルドカードホスト。これは、ワイルドカード証明書の有用性の一部を減らしますが、共有秘密鍵の問題を確実に軽減し、状況によっては役立つ場合があります。それ以外の場合は、 このEntrustの記事 および ホワイトペーパーPDF参照先 で、ワイルドカード証明書を使用する場合の秘密鍵の管理のベストプラクティスについて説明します。
最後に、権威による議論に頼る... Googleがいくつかのプロパティにワイルドカード証明書を使用している の場合、それらは普遍的に悪いものであってはなりません。
:-)
理想的には、証明書/キーが偽装に使用できるサービスのリストは、証明書/キーが使用されることを意図されているサービスのリストと同じである必要があります。
Example.comというドメインがあるとします。そのドメインwww.example.com catpictures.example.com users.example.comの下にさまざまなホスト名を設定します。すべてが同じサーバーでホストされているため、すべてをカバーする1つの証明書を取得します。
次に、より安全性の高いサーバーにsecure.example.comを設定するとします。そのサーバー用に別の証明書を取得するとします。
最初のサーバーの証明書に対応する秘密鍵が盗まれた場合にどうなるかを考えてみましょう。
* .example.comの証明書（ワイルドカード証明書）の場合、攻撃者はそれを使用して、secure.example.comになりすますことができます。
これがwww.example.com catpictures.example.comおよびusers.example.comの証明書である場合、攻撃者はそれを使用して、secure.example.comになりすますことはできません。