SSLと中間者の誤解

私はこの問題に関連するたくさんのドキュメントを読みましたが、まだすべてをまとめることができないので、いくつか質問します。

1. まず、私が理解している認証手順について簡単に説明します。これについては誤解されているかもしれません。クライアントが接続を開始し、サーバーがそれに応答して公開鍵、メタデータ、およびデジタル署名の組み合わせで応答します。信頼できる機関。次に、クライアントは、サーバーを信頼するかどうかを決定し、ランダムなセッションキーを公開キーで暗号化して送信します。このセッションキーは、サーバーに格納されている秘密キーでのみ復号化できます。サーバーがこれを実行すると、HTTPSセッションが開始されます。

2. したがって、上記が正しい場合、問題はそのようなシナリオで中間者攻撃がどのように発生するかです。つまり、誰かがサーバー（例：www.server.com）の応答を公開キーで傍受し、自分がwww.server.comであると思わせる何らかの手段があっても、私のキーを解読することはできません。秘密鍵なし。

3. 相互認証について言えば、それはすべてクライアントIDに関するサーバーの信頼に関するものですか？つまり、クライアントはすでに適切なサーバーと通信していることを確認できますが、サーバーはクライアントが誰であるかを知りたがっています。

4. そして最後の質問は、相互認証に代わるものです。上記の状況でクライアントとして機能する場合、SSLセッションの確立後にHTTPヘッダーでログイン/パスワードを送信するとどうなりますか？ご覧のとおり、接続は既にセキュリティで保護されており、サーバーはこの情報を使用して識別できるため、この情報を傍受することはできません。私が間違っている？相互認証と比較したこのようなアプローチの欠点は何ですか（実装の複雑さではなく、セキュリティの問題のみが重要です）？

SSLに対する中間者攻撃は、SSLの前提条件の1つが破られた場合にのみ実際に可能です。以下に例を示します。

• サーバーキーが盗まれた-攻撃者がサーバーであるように見える可能性があり、クライアントが知る方法がないことを意味します。

• クライアントは信頼できないCA（またはルートキーが盗まれたCA）を信頼します-信頼できるCAキーを保持している人はだれでも、サーバーを装った証明書を生成でき、クライアントはそれを信頼します。現在ブラウザーに存在するCAの数が多いため、これは実際の問題になる可能性があります。これは、サーバー証明書が別の有効な証明書に変更されたように見えることを意味します。これは、ほとんどのクライアントが非表示にするものです。

• クライアントは、信頼できるCAのリストに対して証明書を正しく検証する必要はありません。誰でもCAを作成できます。検証がない場合、「ベンの車と証明書」はVerisignと同じように有効であるように見えます。

• クライアントが攻撃され、偽のCAが信頼されたルート証明機関に挿入されました-攻撃者が好きな証明書を生成できるようになり、クライアントはそれを信頼します。マルウェアは、たとえば偽の銀行サイトにリダイレクトするためにこれを行う傾向があります。

特に＃2はかなり厄介です。信頼性の高い証明書にお金を払っても、サイトがその証明書にロックされることはありません。クライアントのブラウザですべての CA を信頼する必要があります。同様に有効なあなたのサイト。また、サーバーまたはクライアントへのアクセスも必要ありません。

最初に、私が理解している認証手順を簡単に説明します。おそらく、その手順は間違っています。したがって、クライアントが接続を開始し、サーバーが公開鍵、一部のメタデータ、信頼できる機関のデジタル署名の組み合わせで応答します。

サーバーは、X.509証明書チェーンと独自の秘密鍵で署名されたデジタル署名で応答します。

次に、クライアントはサーバーを信頼するかどうかを決定します

正しい。

ランダムなセッションキーを公開キーで暗号化して送り返します。

いいえ。クライアントとサーバーは相互にセッションキーを生成するプロセスを行っており、セッションキー自体はまったく送信されません。

このセッションキーは、サーバーに格納されている秘密キーでのみ復号化できます。

番号。

サーバーはこれを行います

番号。

その後、HTTPSセッションが開始されます。

TLS / SSLのセッションが開始されますが、より多くの工程は、第1があります。

したがって、上記が正しい場合、問題はそのようなシナリオで中間者攻撃がどのように発生する可能性があるかです。

サーバーを偽装し、SSLエンドポイントとして機能します。クライアントは承認手順を省略しなければなりません。悲しいことに、ほとんどのHTTPSセッションでの唯一の承認手順は、ホスト名のチェックです。

つまり、誰かがサーバー（例：www.server.com）の応答を公開キーで傍受した後、何らかの手段で彼がwww.server.comだと思っても、セッションキーを解読することはできません。秘密鍵なし。

上記を参照。復号化するセッションキーはありません。SSL接続自体は安全です。あなたが話している相手が安全でない可能性があります。

相互認証について言えば、それはすべてクライアントIDに関するサーバーの信頼に関するものですか？つまり、クライアントはすでに適切なサーバーと通信していることを確認できますが、サーバーはクライアントが誰であるかを知りたがっています。

正しい。

そして最後の質問は、相互認証に代わるものです。上記の状況でクライアントとして機能する場合、SSLセッションの確立後にHTTPヘッダーでログイン/パスワードを送信するとどうなりますか？ご覧のとおり、接続は既にセキュリティで保護されており、サーバーはこの情報に基づいて識別できるため、この情報を傍受することはできません。私が間違っている？

番号。

相互認証と比較したこのようなアプローチの欠点は何ですか（実装の複雑さではなく、セキュリティの問題のみが重要です）？

ユーザー名/パスワードと同じくらい安全ですが、秘密鍵よりも漏洩がはるかに簡単です。

クライアントとサーバーの間の道を行く人は誰でも、httpsで中間者攻撃を仕掛けることができます。これがありそうもまれでもないと思う場合は、インターネットゲートウェイ全体のすべての SSL トラフィックを体系的に復号化、スキャン、再暗号化する市販の製品があることを考慮してください。これらは、「実際の」ssl証明書からコピーされた詳細を使用してオンザフライで作成されたssl証明書をクライアントに送信することで機能しますが、別の証明書チェーンで署名されています。このチェーンがブラウザの信頼できるCAのいずれかで終了する場合、このMITMはユーザーには見えません。これらの製品は主に企業に「安全な」（警察の）企業ネットワークを提供するために販売されており、ユーザーの知識と同意を得て使用する必要があります。技術的には、ISPやその他のネットワークキャリアによる使用を止めるものは何もありません。（NSA が少なくとも1つの信頼されたルートCA署名鍵を持っていると想定しても安全です）。

ページを提供している場合は、ページの署名に使用する公開鍵を示すHTTPヘッダーを含めることができます。これは、「安全な」接続についてMITMをユーザーに警告するのに役立ちますが、これは最初に使用するときの信頼技術です。ボブが「実際の」公開鍵ピンの記録をまだ持っていない場合、マロリーは文書のpkpヘッダーを書き換えるだけです。このテクノロジー（HPKP）を使用しているWebサイトのリストは非常に短いです。それは彼らの信用にgoogleとdropboxが含まれています。通常、httpsインターセプトゲートウェイは、HPKPを使用するいくつかの大きな信頼できるサイトのページを通過します。予期していないときにHPKPエラーが表示された場合は、注意してください。

パスワードに関しては、要求をルーティングできるように平文である必要があるドメイン名を除いて、https接続のすべてがhttpsによって保護されます。一般に、ログやブックマークなどでぶらぶらする可能性があるクエリ文字列にはパスワードを入れないことをお勧めします。ただし、httpsが危険にさらされない限り、クエリ文字列は表示されません。

1. 正しい
2. 正しくない。この種の攻撃では、反復サーバーが要求を受け取り、それを宛先に送信します。そして、その結果であなたに返答します。実際には、コミュニケーションを行う実際のサーバーではなく、中間者サーバーが安全な接続を確立します。そのため、証明書が有効で信頼されていることを常に確認する必要があります。
3. 正しいかもしれない
4. 安全な接続が信頼できると確信している場合は、ユーザー名/パスワードを送信しても安全です。

セッションキーに関する部分を除いて、あなたが言ったことはすべて正しいです。CAの目的は、中間者攻撃を無効にすることです。それ以外はすべてSSL自体によって行われます。クライアント認証は、ユーザー名とパスワードのスキームに代わるものです。