マルチテナンシー、SSL証明書、およびサブジェクトの別名

Question

X509仕様を使用すると、CAは "Subject Alternative Name" 拡張子を使用して、複数のホスト名に対して単一の証明書を発行できます。

スペックから：

サブジェクトの別名拡張により、IDを証明書のサブジェクトにバインドできます。これらのIDは、証明書のサブジェクトフィールドのIDに加えて、またはその代わりに含めることができます。

これには多くの用途があります。特に、複数のサイトが共存するホスティング/リバースプロキシの状況を検討してください。これらのサイトは特に相互に信頼しておらず、いかなる種類の提携もありません。それらは同じサーバーによってホストされているだけなので、同じ証明書を共有しています。

これは想像以上に危険ですか？
一見すると、サイトは互いに信頼されていないため、siteAはsiteBと同じ秘密鍵を使用するため、SSLを介してもsiteBがsiteBを偽装する可能性があると言えます。 DNSはまだスプーフィングが必要ですが、そうする方法はいくつかあります（たとえそれが簡単ではない場合でも）。
Am間違っています、ISここに表示されていない他の暗号化（または他の）緩和策はありますか？

Thomas Pornin · Accepted Answer

すべてのテナントが秘密キーのコピーを持っている場合、まあ、彼らはすべてそれを持っています。つまり、お互いを偽装することができます。 SSLの「DHE」暗号スイートを使用しない限り、他のテナントとクライアント間のトラフィックを復号化することもできます。これにより、この特定の問題が取り除かれます。これは Perfect Forward Secrecy として知られています。 DHEはスプーフィングの問題に対して何も実行せず、クライアントソフトウェアが同意した場合にのみ使用できます。

その場合、秘訣はではなく各テナントに秘密鍵を与えることです。それらに同じ証明書を共有させる代わりに、それらに同じSSLサーバーを共有させます。証明書を使用する単一の信頼できるHTTPSサーバーを実行し、復号化されたHTTPトラフィックを関連するテナントに転送します（名前はHTTPヘッダーで指定されています-不要 [〜＃〜] sni [〜＃〜] ここでサポート）。確かに、リバースプロキシの状況です。そのような設定は安全です（テナントには何も与えられません）。ただし、テナントは共有SSLサーバーをtrustする必要があります（これは、テナントを相互に信頼するように要求するよりもさらに優れています）。 client証明書の使用。

Adi · Answer

はい、それはですリスクと同じくらい危険ですあなたは間違っていません、そしてAFAIK、私はあなたが何かを逃しているとは思いません。

公開鍵に署名する同じ証明書を共有する複数のエンティティは、同じ秘密鍵を共有することを意味します。良くないこと^TM。 site1.comがsite2.comを信頼しない場合は、サブジェクトの別名（ [〜＃〜] san [〜＃〜] ）証明書を使用するように設定しないでください。

適切なCAは、証明書を要求するエンティティがSAN（ドメイン名、IPアドレス、電子メールアドレスなど）で定義されたサブジェクトに対する所有権を持っていることを確認します。

結論として、SAN証明書は、対象となるサブジェクトが互いに信頼し合う場合にのみ使用する必要があります。同じ証明書を使用するサイト（1つ DMZで言及）は、SEサイトの場合です。stackoverflow.comはsuperuser.comとは異なるサイトですが、それぞれを信頼します他のものと同じエンティティに属しています。

gowenfawr · Answer

@Adnanと@Thomas Porninの両方が三脚の最初の脚に触れます：キーが共有プロバイダー（CDNなど）によってのみアクセスされる場合、セキュリティは必ずしも低くはなく、接続されていないパーティによって共有される場合は、セキュリティは途方もなく低いです。

三脚にはメンテナンス用の2つ目の脚があります。鍵は共有プロバイダー（HostCo）のみが保持しているため、セキュリティは問題にならないものとします。 HostCoには20のテナントがあり、サブジェクトの別名（SAN）を使用してキーに詰め込みます。すごい！ 6月が通過し、7月が到着し、3人のテナントが去り、4人の新しいテナントが現れます。おっと！追加/変更を反映して発行された新しい証明書を取得する時間。すごい。おっと！ 8月が来る...これがどこへ行くのか見てください？ SANへの名前のプールがかなり静的でない限り、複数のSANで証明書を再実行するメンテナンスは、時間の経過とともに愚かになります。

三脚の3番目の脚はお金です。 HostCoは、SAN証明書を使用して外に出て20証明書を購入するよりも安くなるかもしれません。テナントは本当に接続されていないユニットであるため、このレッグは実際には意味がありません。 HostCoは、個別の証明書のコストをそれらに渡すだけです。たとえば、Massive Dynamicは、その子会社の273の子会社すべてがWebサイトの証明書にお金を節約しなければならないという同じ経済的インセンティブはありません。提供しています。

それは3つの著しく揺れる足です。オプションがあれば、そのスツールに腰を下ろすことはできません。