私たちの会社は、いくつかのWebサイトを備えたWebサーバーを使用しています(プライベートおよびパブリック、HTTPおよびHTTPS経由、低リスクおよび高リスクなど、オンライン決済やその他の機密データなど)。
前回のプロジェクトでは、Webサービスを介してパートナー企業と通信しました。彼らは、接続を保護するために、自分で発行した独自の証明書を使用したいと考えていました。そのため、Webサーバーにルート証明書「PrivateCompany Root CA」をインストールする必要がありました。
これは正確にどれほど悪いのですか?セキュリティが改ざんされる可能性があるのはどのシナリオですか?
そのため、Webサーバーにルート証明書「PrivateCompany Root CA」をインストールする必要がありました。
どうして?グローバルに信頼されたCAは、ブラウザーなどの汎用クライアントで役立ちます。
ただし、カスタムクライアントから特定のWebサービスを利用する場合は、そのCAをローカルに追加できます。適切なSSLクライアントを使用すると、証明書の検証に影響を与えることができます。たとえば、CAのカスタムリストを指定します。
このようにすると、そのCAはそれらの要求を傍受するためにのみ使用できます。 CAとターゲットドメインは同じエンティティによって所有されているため、大きなリスクはありません。標準のCAを使用するよりも安全です。
これは正確にどれほど悪いのですか?
ユーザー(またはCA証明書を盗んだ人)がサーバーに対してMitMの位置にいる場合、クライアントがグローバルCAストレージを使用するSSLトラフィックを傍受できます。ドメインに限定されません。
インストールしたCAとの完全な信頼のみがあります。つまり、信頼できるCAが署名できる証明書に制限はありません。そのため、所有していないサイト(banking.comなど)の偽の証明書に署名することもでき、それらを受け入れます。
パートナーとの通信方法はわかりませんが、Perl、Pythonなどの言語では、この特定の通信でのみ使用されるCAストアを指定できます。このようにして、通常の通信とパートナーとの通信では、信頼されたCAの異なるセットを使用します。
他の認証局(CA)ルート証明書のセキュリティに関する限り、承認された認証局のSSL証明書を実装する場合、問題は予期されません。
セキュリティ証明書が信頼できる認証局からのものである場合、セキュリティ上の問題が発生することはありません。
会社ができることはある程度制限されています
名前の制約(適用されている場合)
拡張キー使用法(適用されている場合)
もちろん、これは、ルートまでのチェーン内のすべての中間証明書を適切に検証するクライアントソフトウェアに依存します。
一部のクライアントソフトウェアはチェーンを検証せず、特定のチェックをスキップする可能性があるため、チェーンが「適切に構成」されていて、使用を特定の目的やドメインに制限している場合でも、証明書は有効と見なされます。
ソフトウェアの問題の大きさを理解するには、証明書の検証を無効にする 多くのC#アプローチ について説明しているこのgoogle検索を見てください。