SSLと中間者の誤解
私はこの問題に関連する文書をたくさん読みましたが、まだすべてをまとめることができないので、いくつか質問をしたいと思います。
まず最初に、クライアントが接続を開始し、サーバーが公開キー、一部のメタデータ、およびデジタル署名の組み合わせで応答する接続を開始することを理解した上で、簡単に認証手順を説明します。信頼できる機関。次に、クライアントは、サーバーを信頼するかどうかを決定し、公開キーでランダムなセッションキーを暗号化して送り返します。このセッションキーは、サーバーに保存されている秘密キーでのみ解読できます。サーバーがこれを実行すると、HTTPSセッションが開始されます。
したがって、私が上で正しいなら、問題はそのようなシナリオで中間者攻撃がどのように発生する可能性があるかということです。つまり、誰かが公開鍵でサーバー（www.server.comなど）の応答を傍受し、彼がwww.server.comであると思わせる何らかの手段を持っているとしても、彼はまだ私のセッション鍵を解読することができないでしょう秘密鍵なし。
相互認証について言えば、クライアントIDについてのサーバーの信頼についてですか？つまり、クライアントはすでに適切なサーバーと通信していることを確信できますが、サーバーはクライアントが誰であるかを知りたいのですよね？
そして最後の質問は、相互認証の代替案です。上記の状況でクライアントとして行動する場合、SSLセッションの確立後にHTTPヘッダーでログイン/パスワードを送信するとどうなりますか？ご覧のように、接続は既にセキュリティで保護されており、サーバーはその情報に基づいて識別できるため、この情報は傍受できません。私が間違っている？相互認証と比較した場合のこのようなアプローチの欠点は何ですか（実装の複雑さではなく、セキュリティの問題のみが重要です）？
SSLに対する中間者攻撃は、SSLの前提条件の1つが破られている場合にのみ実際に可能です。以下に例を示します。
サーバーキーが盗まれました-攻撃者がサーバーに見える可能性があり、クライアントが知るために方法はありませんがあることを意味します。
クライアントは、信頼できないCA（またはルートキーが盗まれたCA）を信頼します。信頼できるCAキーを保持しているユーザーは、サーバーを装って証明書を生成でき、クライアントはそれを信頼します。現在、ブラウザには既存のCAが多数存在するため、これは実際の問題になる可能性があります。これは、サーバー証明書が別の有効な証明書に変わるように見えることを意味します。これは、ほとんどのクライアントがあなたから隠しているものです。
クライアントは、信頼できるCAのリストに対して証明書を正しく検証する必要はありません-誰でもCAを作成できます。検証なしでは、「Ben's Cars and Certificates」はベリサインと同じくらい有効であるように見えます。
クライアントは攻撃され、偽のCAが信頼されたルート機関に注入されました-攻撃者が好きな証明書を生成でき、クライアントはそれを信頼します。マルウェアは、たとえば、偽の銀行サイトにリダイレクトするためにこれを行う傾向があります。
特に＃2はかなり厄介です。たとえあなたが非常に信頼できる証明書の代価を払っても、あなたのサイトは決してその証明書にロックされないでしょう、あなたは信頼する必要がありますall彼らはあなたのサイトのために同じくらい有効な偽の証明書を生成できます。サーバーまたはクライアントへのアクセスも必要ありません。
まず、私が理解している認証手順について簡単に説明しますが、おそらくその手順に間違いがあるでしょう。したがって、クライアントは接続を開始し、サーバーは公開キー、一部のメタデータ、および信頼できる機関のデジタル署名の組み合わせで接続に応答します。
サーバーは、X.509証明書チェーンと、独自の秘密鍵で署名されたデジタル署名で応答します。
その後、クライアントはサーバーを信頼するかどうかを決定します
正しい。
ランダムセッションキーを公開キーで暗号化して送り返します。
いいえ。クライアントとサーバーは、セッションキー自体がまったく送信されない相互セッションキー生成プロセスに関与します。
このセッションキーは、サーバーに保存されている秘密キーでのみ解読できます。
番号。
サーバーはこれを行います
番号。
その後、HTTPSセッションが開始されます。
TLS/SSLセッションが開始されますが、最初にさらに手順があります。
したがって、上記の説明が正しければ、問題はそのようなシナリオで中間者攻撃がどのように発生するのかということです。
サーバーになりすまし、SSLエンドポイントとして機能する。クライアントは、承認手順を省略する必要があります。残念ながら、ほとんどのHTTPSセッションでの唯一の承認手順はホスト名のチェックです。
だれかが公開鍵でサーバー（例：www.server.com）の応答をインターセプトし、何らかの手段で彼がwww.server.comであると考えさせても、彼はまだ私のセッションキーを解読できません秘密鍵なし。
上記を参照。復号化するセッションキーはありません。 SSL接続自体は安全です。これは通話相手であり、安全ではない可能性があります。
相互認証について言えば、クライアントIDについてのサーバーの信頼についてですか？つまり、クライアントはすでに適切なサーバーと通信していることを確認できますが、サーバーはクライアントがだれであるかを知りたいのですよね？
正しい。
そして最後の質問は、相互認証の代替案です。上記の状況でクライアントとして行動する場合、SSLセッションの確立後にHTTPヘッダーでログイン/パスワードを送信するとどうなりますか？ご覧のように、接続はすでにセキュリティで保護されており、サーバーはその情報に基づいて識別できるため、この情報を傍受することはできません。私が間違っている？
番号。
相互認証と比較したこのようなアプローチの欠点は何ですか（実装の複雑さではなく、セキュリティの問題のみが重要です）？
ユーザー名/パスワードと同じくらい安全です。秘密鍵よりも簡単に漏えいします。
クライアントとサーバーの間を移動している人はだれでもhttpsに対する中間攻撃を仕掛けることができます。これがありそうにない、またはまれだと思われる場合は、商用製品がある 体系的に復号化、スキャン、再暗号化することを考慮してくださいallインターネットゲートウェイを通過するSSLトラフィック。クライアントは、「実際の」SSL証明書からコピーされた詳細を含むオンザフライで作成されたSSL証明書をクライアントに送信しますが、別の証明書チェーンで署名されます。このチェーンがブラウザの信頼できるCAのいずれかで終了すると、このMITMはユーザーには見えなくなります。これらの製品は主に企業に販売され、企業ネットワークを「保護」（警察）し、ユーザーの知識と同意を得て使用する必要があります。技術的には、ISPや他のネットワークキャリアによる使用を止めるものは何もありません。 （NSA 少なくとも1つの信頼されたルートCA署名キーがあります と想定しても安全です。）.
ページを提供している場合、 HTTPヘッダーを含めることができます ページに署名する必要がある公開キーを示します。これは、ユーザーに「安全な」接続をMITMに警告するのに役立つ場合がありますが、初回使用時の信頼技術です。 Bobが「実際の」公開キーピンのレコードをまだ持っていない場合、Malloryはドキュメントのpkpヘッダーを書き換えます。このテクノロジー（HPKP）を使用するWebサイトのリストは、非常に短いです。 Googleとdropboxが含まれています。通常、https-interceptingゲートウェイは、HPKPを使用する少数の大きな信頼できるサイトのページを通過します。予期しないときにHPKPエラーが表示される場合は、注意してください。
パスワードについては、https接続のすべてがhttpsで保護されていますが、ドメイン名は要求をルーティングできるようにクリアである必要があります。一般に、パスワードをクエリ文字列に入れないことをお勧めします。パスワードは、ログやブックマークなどに潜むことができますが、httpsが侵害されない限り、クエリ文字列は表示されません。
- 正しい
- あまり正しくない。この種の攻撃では、中間サーバーがリクエストを取得し、ユーザーに代わって宛先に送信します。その後、結果を返信します。実際には、通信する予定の実際のサーバーではなく、ユーザーとの安全な接続を行う中間者サーバーです。そのため、証明書が有効で信頼されていることを常に確認する必要があります。
- 正しいかもしれません
- セキュリティで保護された接続が信頼できると確信している場合は、ユーザー名/パスワードを送信しても安全です。
セッションキーに関する部分を除き、あなたが言ったことはすべて正しいです。 CAのポイントは、中間者攻撃を打ち負かすことです。他のすべてはSSL自体によって行われます。クライアント認証は、ユーザー名とパスワードのスキームに代わるものです。