ウェブサーバーを作成して、ホスト名を "google.com
"、そのサーバーからCSRを作成し、それを署名のために認証局に送信しますか?私が見つけることができる最も安価で危険な服を選択するとします。
うまくいきますか?人々がこれを行うのを防ぐためにどのようなメカニズムが整っていますか?
DNSレコードが実際のGoogleを指しているため、google.com宛てのトラフィックを受信しないことは承知していますが、この方法を使用してMitMがGoogleトラフィックを攻撃する可能性があります。ユーザーが何も知らずにローカルトラフィックを自分のサーバーにリダイレクトすることもできます。
これは、特にGoogleのような会社にとっては、あなたが思っている以上の問題です。なぜなら、この種の悪意のある攻撃の頻繁なターゲットだからです。しかし、いくつかの保護手段があり、私たちの保護は時間とともに改善されています。
証明書に不適切な署名をさせてはなりません。各CAには、特定のドメインの証明書を購入する資格を確認するための独自のメカニズムがありますが、通常は、次の1つ以上を実行することを含みます。
しかし、CAがいくつでもあると、驚くほど多くの不適切な証明書が発行されます。これは、「文字通り1つの仕事があった」の場合ですが、間違いが発生することを受け入れる必要があります。
CAの側に説明責任と透明性の意外な欠如があるので、Googleは Certificate Transparency でそれについて何かをすることにしました。
これは、CAが署名したすべての証明書の公開ログです。証明書がログに表示されない場合、それは有効ではなく、ログは追加専用です。戻って履歴を消すことはできません。それはまだ比較的新しいですが、ChromeはすべてのEV CAを含む特定のCAですでに必要です。ログをたどって、ドメインが表示されないはずのときに表示されるかどうかを確認できます。これを簡単にするためにツールはまだ進化していますが、非常に有望なテクノロジーです。
より安全なブラウザを使用すると、ドメイン所有者は1つ以上の公開鍵をドメインに「固定」できます。これは、PKIシステム全体の終点であり、信頼をブラウザーに直接注入します。ドメイン所有者は、HTTPヘッダーを介して、特定の公開鍵を持つ証明書のみを許可するようにブラウザーに指示することができ、実際にそのアサーションをブラウザー自体にプリインストールして出荷することができます。これにより、有効なCA署名がある場合でも、不正な証明書が使用されるのを防ぎます。
多分。 DNSSECを使用すると、DNSレコードに署名できます。つまり、公開鍵署名をDNSのすぐそこに配置できます。つまり、第三者の認証局が鍵に署名する必要がない必要はありません。これは非常に洗練されたソリューションですが、DNSSECはまだまだ先の道です。多くのOSで使用することはできず、採用は氷河期に進んでいます。
特定のドメイン名の証明書に誰かが署名する前に、DNSの所有権を証明する必要があります。
GoogleのドメインでCSRを作成するだけでは十分ではありません。
認証局が実際に所有権を証明していないドメインの有効な証明書を提供した場合、そのCAはすぐに信頼されなくなり、そのルート証明書はトラストストアから削除されます。
理論的には、現在の認証局ではこれが可能です。しかし、多くのセーフガードが設置されています。しかし、これはすでに答えられています。
ただし、これは letsencrypt 認証局ではできません。 ACMEプロトコル を使用してドメイン名の所有権を証明するためです。
基本的に、ACMEプロトコルを使用してletsencrypt認証局のサーバーと通信するletsencryptクライアントを実行して、主張するドメイン名を所有していることを証明します。これが証明されると、無料で自動的に新しい証明書が発行されます。
簡潔な答え; はい、動作します
証明書が機能する方法を考えると、それを実行するのに十分だらけのCAを見つけることができた場合、あなたはGoogle.comを示す証明書で終わる可能性があります。
問題は、CAがあなたの身元を確認することになっているということです。それが彼らの全目的です。それで悪い仕事をする人は長くはないでしょう。
通常、これらの信頼性の低いCAは、信頼チェーンの4番目と5番目のレベルであり、通常、迅速に識別され、信頼チェーンから削除されます。
とはいえ、証明書だけを見る場合、CAは防御の最後の行であるため、適切な調査なしに自分がgoogle.comであることを証明するものを見つけた場合、Googleであることを証明する証明書が作成されます。 .com。 (ここでもおそらく非常に短い時間)
これは攻撃の深刻なベクトルであり、大規模なサーバーでは問題であることに注意することが重要です。また、悪意のあるコードを介してルート証明書をクライアントに追加できる場合は、攻撃の可能性があります(あまり使用されません)。
DNSSECのような作品にはいくつかの「修正」がありますが、それが広く使用されるようになるまでにはしばらくかかります。
今日の最善の保護は、クライアントのルート証明書が正常であることを確認することであり、追加することではありません。