web-dev-qa-db-ja.com

信頼できるCAでHTTPSペイロードを傍受することはできますが、間違ったサーバーに送信することはできますか?

CAにサーバー用の証明書と秘密キーを生成させます。ただし、私のサーバーにはドメイン名がなく、そのIPは動的で静的ではないため、クライアント側ではホスト名の検証を無視する必要があります。これは真実ではなく、従来のHTTPSではないことを知っています。議論のために、これは発生しなければならないことを言いましょう。

HTTPSポストを介してサーバーにペイロードを送信しようとするクライアントがあります。ハンドシェイク中に、サーバーのCAを確認し、有効であればペイロードを送信します。サーバーがリクエストを拒否してもしなくてもかまいません。クライアントは発生し、ハンドシェイクしたら忘れます。クライアントは、信頼できるCAを除くすべてのCAを拒否します。

このシナリオで、サーバー以外に、クライアントが送信するペイロードを誰かが見ることは可能ですか?たとえば、HTTPSを介してIPに要求を送信し、それが自分が欲しいサーバーだと思ったとしますが、実際にはそれは悪意のある人物です。とにかく、彼らが実際のサーバーになりすましたり、偽装したりして、POSTのペイロードを確認するためにリクエストを受け入れることができますか?ペイロードを取得するためには、「私はサーバーであり、信頼するCAによって署名された証明書を持っている」と私が理解できる必要があります。しかし、サーバーの証明書とCAの両方がない場合は、どうすればよいでしょうか。サーバーの証明書の秘密鍵はどこにありますか?

はいの場合、サーバーとクライアントだけが自己署名機関のように知っているCAを使用するとどうなりますか?それが理由ではないとしても、何か変化はありますか?

1
user99999991

その接続を傍受することを可能にするいくつかのシナリオがあります:

  • 検証コードは実際には正しく検証されていません。その場合、別のCAがコードによって有効であると見なされる証明書に署名する可能性があります。
  • CAの秘密鍵が漏えいしたり、失われたり、他の方法で侵害されたりします(たとえば、それが因数分解されるため)。その場合、鍵を所持している誰もが、コードによって有効であると見なされる証明書に署名できます。
  • 実際の証明書と同じもの(侵害されたキー)。
  • CAが完全に制御されていない可能性があります(つまり、独自のCAではありません)。その場合、そのCAによって署名された証明書(たとえば、CAがドメインTLS証明書のプロバイダー(たとえば、暗号化しましょう))はコードによって有効であると見なされます。

最後の可能性を軽減するために、クライアントアプリケーションで明示的に信頼する自己署名認証局を使用できますが、これには通常の注意事項が含まれています。つまり、何をしているのかを理解し、CA自体を安全に保ちます。

しかし、サーバーの証明書とCAの両方がない場合は、どうすればよいでしょうか。サーバーの証明書の秘密鍵はどこにありますか?

この質問は、PKIまたはTLSの仕組みを実際に理解していないため、独自のCAをホストするとセキュリティリスクが高まる可能性があることを示唆しています。

一般的な考え方は、CAは証明書が展開されているのと同じマシン上にあるnotであるということです。独自のCAの採用を進める前に、PKI、TLS、証明書のピン留め、および信頼チェーンについて読んでください。

1
Tobi Nary