SSLは、Webサイトを中間者攻撃から保護することを目的としています。
しかし、誰かがそれを行うことができる場合、CAに新しい証明書を要求し、CAからサーバーに送信されるトラフィック(明らかに暗号化できない)を変更して、CAが要求するテストに合格することはできません。所有権の確認?
認証局をMitMできることは、想像するほど簡単ではありません。あなたは彼らが所有権を評価するためにどのマシンを使用しているのか知りません、そしてうまくいけば彼らはスターバックスのwifiでこれをしていないでしょう。
証明書は、マシンまたはIPアドレスではなく、ドメイン名に適用されるため、通常、特定のHTTPサーバーからの応答をテストしても所有権は確認されません。たとえば、 CAに対するMozillaの要件 を見てみましょう。
証明書の署名リクエストの検証は、次の要件を満たすか超える場合は許容できると見なします。
- 証明書サブスクライバーによって提供されるすべての情報は、証明書に含まれる前に、独立した情報源または代替の通信チャネルを使用して検証する必要があります。
- 証明書が電子メールメッセージのデジタル署名または暗号化に使用される場合、CAは、要求を送信したエンティティが証明書で参照されている電子メールアドレスに関連付けられている電子メールアカウントを制御しているか、または電子メールアカウントの所有者によってアカウント所有者に代わって行動する。
- 証明書がSSL対応サーバーで使用される場合、CAは、証明書署名要求を送信したエンティティが証明書で参照されているドメインを登録したか、ドメイン登録者によって動作することを承認されていることを確認するために妥当な措置をとります登録者の代理。
- 拡張検証に使用され、拡張検証としてマークされる証明書については、CAは拡張検証証明書の発行と管理のガイドラインバージョン1.4以降に準拠しています。
したがって、CAとDNSサーバーの間の接続をMitMするか、サイトのDNS(おそらく1つ)を危険にさらす必要があります。
証明書発行者は、ドメイン名の証明書を、そのドメインの制御権があることを証明できる人にのみ発行することを約束します
HTTPとSMTPの両方に対する中間の攻撃者が発行者をだまして、攻撃者に資格のない「ドメイン制御検証済み」の証明書を取得するために使用される可能性があると思います。この詐欺的な証明書は、サイトを偽装するために使用される可能性があります。 HTTPSトラフィックに対する中間者攻撃。 HTTPとSMTPサーバーが異なる場合、2つのMITM攻撃が必要になります。
アドレスバーに長い緑色のメッセージを表示する拡張された検証証明書(銀行で使用されるような)は、ドメイン名の制御を証明するだけではなく、おそらく簡単に不正に取得することはできません。
HPKP(HTTP Public Key Pinning) は、次のようなHTTP応答ヘッダーを介して配信されるセキュリティポリシーです。
- ホストがユーザーエージェントに、将来ホストから受け入れる暗号化IDに関する情報を提供できるようにします
- 不正な証明書が発行される可能性のある認証局でのセキュリティ侵害からホストWebサイトを保護します
- ホストが指紋のセットを、ユーザーエージェント(UA)が受け入れるサイトの暗号化IDに配信することを許可します。
- trust On First Use(TOFU)メカニズムであり、UAは、ヘッダーをそのまま受信するために、Hostと少なくとも1つのセキュアセッションを確立する必要があります。ヘッダーが受信されると、UAはヘッダーに含まれるディレクティブに従ってポリシーをキャッシュおよび適用します
あなたの質問への回答:a HPKPを実装するホストは、ハッカーが新しい/不正なSSL証明書を使用することを防ぎます。
HPKPは簡単にセットアップできるかもしれませんが、慎重に実行する必要があります バックアップが必要です :
- 最も理想的なソリューションは、現在のTLS証明書のフィンガープリントと少なくとも1つのバックアップを含めることです
- バックアップは、証明書署名要求(CSR)のフィンガープリントにすることができるため、バックアップ証明書を購入する必要がありません。
- 証明書の秘密鍵が侵害された場合、CSRを使用して新しい公開鍵の署名を要求できます(これを機能させるには、CSRを新しいRSA鍵ペアで作成し、安全にオフラインで保存する必要があります。 )
- cSRのフィンガープリントはすでにHPKPヘッダーにあったため、新しい証明書への切り替えは問題なく実行できます。
- この方法を使用すると、CAが侵害された場合、自分のCAであっても、ドメインに対して発行された不正な証明書は、 HPKPヘッダーを受信したbrowser
- 不正な証明書のフィンガープリントがブラウザによって受信およびキャッシュされていないため拒否され、サイトへの接続は許可されません
つまり、すべてのバックアップが失われた場合、次のようになります。
現在の証明書の有効期限が切れるまでは、新しいポリシーをすべての訪問者に提供できます。
おそらくこれが、現在HPKPを実装しているWebサイトが少ない理由です( securityheaders.io のいくつかの例をスキャンしてください。ほとんどのオンラインバンクが実装していない場合があります。例 JP Morgan ))。しかし、それはあなたの質問によって提起された問題に特に対処/解決します。
証明書のセキュリティの基本は、サードパーティ(発行者)が証明書がドメインの適切な権限を持つユーザーに配信されたことを証明することです。
クライアントとして発行者を信頼する場合、発行者が署名した証明書を信頼できます。
考えられる詐欺は次のとおりです。
誰かが彼がドメインを所有していることを示す偽の文書を持ってくる。できるかもしれませんが、発行者はその部分が彼らの本当の仕事であり、簡単にだまされることができるならば誰も彼らをもはや信頼しないので、それについて非常に慎重でなければなりません
誰かが発行者をハッキングし、証明書の署名を許可する有効な秘密鍵を取得します。深刻な証明書発行者のセキュリティルールはこれを非常に困難にする傾向があり、盗まれた証明書はすぐに取り消される可能性があります
実際には、偽の証明書を取得するコストはそれだけの価値はないと一般に想定されています。実生活で、Web上の情報を盗むもっと簡単な方法は他にもたくさんあります。
$ 5レンチ …で何ができるかを決して忘れないでください
もちろん、政府機関のことを考えると、状況が異なる場合があります。私はそれが本当かどうかは本当の証拠はありませんが、それは国家安全保障が本当に心配していたと思います、彼らは合法的傍受をするために第三者ドメインの有効な証明書を要求することができました。