web-dev-qa-db-ja.com

SSL証明書の秘密鍵を共有するとどのような問題が発生しますか?

シナリオ:私はSと呼ぶクライアントのWebサイトをホストしています。Sはドメインs.comを所有しており、実際にWebサイトをホストするサーバーを所有しています。 Sは自分のWebサイトでSSLを有効にしたいと考えています。

サーバーで秘密鍵とCSRを生成し、CSRをSに送信して、CAに送信できるようにしました。

ただし、すべてのクライアントと同様に、Sは安価です。彼らは新しい証明書にお金を使いたくありません。代わりに、*.s.comの既存のSSL証明書とそれに対応する秘密鍵を提供したいと考えています。この証明書とキーは、SおよびSの他のベンダーの一部によってすでに使用されています。

これは悪い考えであることはすでに知っていますが、なぜですか?これは現在、そして将来的には潜在的にどのような問題を引き起こしますか?

ボーナスポイントとして、このような秘密キーを共有すると、PCI標準のコンテキストで問題が発生しますか?

22
josh3736

ワイルドカード証明書が不適切である理由はいくつかあります。

  • セキュリティレベルの異なるシステムで同じ秘密キーを使用する必要があるため、キーは最も保護されていないシステムと同じように機能します。それをサードパーティベンダーに提供することは本当に悪い考えであり、それは完全にあなたのコントロールから逃れるためです。
  • ワイルドカード秘密鍵がインストールされている場所を正確に示す詳細な記録を保持する必要があります。これにより、ワイルドカードを交換する必要がある場合に、すべてのサイトで「Where is Waldo」をプレイする必要がなくなります。
  • 最も重要なことは、秘密鍵とワイルドカード証明書がいずれかの時点で盗まれた場合、攻撃者はそのワイルドカードスペースでanyシステムになりすますことができます。よくある間違いは、「セキュリティの低いシステムではワイルドカード証明書を使用しますが、すべての重要なシステムでは名前付き証明書を使用する」ということです。まったく逆のことを行う必要があります。攻撃者が* .s.comを持っている場合、他の証明書を使用しているかどうかに関係なく、.s.comスペース内の任意のドメインになりすますことができます。したがって、ワイルドカードを含む「www.s.com」と、1回限りの証明書を含む「login.s.com」がある場合、攻撃者は「login.s.com」の内容に関係なく「login.s.com」になりすますことができます。 。
  • 盗まれたワイルドカードキーを利用する最も簡単な方法は、DNSポイズニングまたは不正なワイヤレスAPを使用することです。

そうは言っても、リスクを評価する必要があります。友人Sがすでにこのワイルドカード証明書とキーをすべてのベンダーに提供している場合、それを受け入れることを拒否しても、彼のリスクは大幅に低下しません。あなたはただ頑固で非協力的であるように見え、彼のビジネスを失うでしょう。教育に最善を尽くしますが、気にしない人もいることを理解してください。

ただし、彼がPCI-DSSに準拠している場合は、秘密暗号化キーへのすべてのアクセスのログがあるはずなので、彼が準拠していないと確信しています。 PCI-DSSに慣れている他の人にそれを拡張させます。

25
mricon

SSLサーバーが使用する秘密鍵にアクセスできる人は誰でも、次のことを行う技術的権限を持っています。

  • 証明書に記載されている名前と一致する名前のサーバーを偽装します。
  • 受動的に盗聴されたセッションを復号化します(SSLセッションが perfect forward secrecy を提供する「DHE」暗号スイートの1つを使用する場合を除きますが、そのようなスイートがデフォルトで選択されることはめったになく、誰かが明示的に設定する必要があります)。

したがって、同じ秘密鍵を多くの人々に与えることは、本当にすべてを信頼し、彼らを互いに信頼させることです。 「あなたを信頼する人」は、本当に「あなたを裏切る力を持つ人」を意味する表現であることを忘れないでください。

一般的に、秘密の値が2人以上の人に知られると、それはもはや秘密ではなく、ちょっと控えめです。また、忘れっぽさを強制することはできないため、クライアントSが、Sが秘密鍵のコピーを提供したベンダーの1つとの取引を中止したい場合、すべてをキャンセルする必要があります(証明書を取り消し、新しい証明書を作成して、新しいキー、そしてそれを配布します)-あるいは、Sは騙しやすさのスケールで1レベル上に行くことができます、そしてちょうど仮定誰もが正直であり、有能で、取引関係がなくなったベンダーは、それでもなお、バックアップテープや精巧なインターンを通じて漏洩することなく、秘密鍵を処理します。

また、ワイルドカード証明書のサポートは、歴史的に問題の原因であったため、少し不安定であることが知られています(それ自体ではありませんが、対応する秘密鍵を盗もうとする悪者の迷惑の力を増幅させます)。ブラウザベンダーは、恣意的で変化する方法でそれらを制限する傾向があります。

SSLサーバー証明書 無料 を提供するCAがあります。無料の証明書が高すぎるのを見つけるには、どれくらい安くなければなりませんか?

12
Thomas Pornin

多くの(信頼できる)サーバーで同じ証明書を使用しても、それ自体では問題は発生しません。

主な問題は、秘密鍵が間違った手に渡った場合です(多くのベンダーのいずれかから、あなたが含めました)。

  • 違反について知るのは困難です。証明書を持っている人やマシンが多いと、違反の可能性が高まり、違反を発見する可能性が低くなります。 S.comが比較的価値の高いターゲットである場合、すべてのサービスで同じ証明書を使用することは、潜在的なハッカーが悪用する最も弱いサーバーを選択できることも意味します。

  • 証明書を取り消す必要がある場合、すべてのベンダーは、クライアントが証明書を拒否しないように、すぐに新しい証明書に置き換える必要があります。これは、クライアントが証明書を取り消すことを望まない可能性があることも意味します(「面倒すぎる」ため)。異なるベンダーが異なる証明書を持っている場合、漏洩した証明書のみを取り消す必要があり、その単一のベンダーのみが新しい証明書をインストールする必要があります。

7
Joel L