SSLシナリオでのman-in-the-middle攻撃
Man-in-the-middle攻撃がWebサーバーにどのように影響するかを理解しようとしています。
自己署名証明書を持っています。この証明書は、man-in-the-middle攻撃によって偽造される可能性があります。つまり、ブラウザから送信するものはすべて傍受され、変更されますか？
リクエストが変更された場合、サーバー上の証明書が異なるため、Webサーバーによって復号化されません。これは正しいです？
ブラウザから送信されたリクエストは傍受され、リダイレクトされる可能性がありますが、サーバー上のデータは影響を受けません。これは正しいですか？
私は証明書の背後にある理論を理解し始めていますが、誰かが中間者攻撃の実際の例を提供し、それがどのような問題を引き起こしたかを確認できれば素晴らしいと思います。
ありがとうございました
あなたの質問 に対する以前の回答で述べたように、man-in-the-middle攻撃（成功した場合）は、暗号化されたチャネルとの間でやり取りされるすべてのデータを所有できます。
自己署名と信頼されたルートから発行された証明書は偽造される可能性があるため、信頼されたルートからユーザーに発行する場合でも、誤った安心感に惑わされないでください。私が信頼できるルートによって発行された問題で克服しなければならない唯一の問題は、私が彼らのコンピューターを毒殺したときにあなたのユーザーに私のものを受け入れさせることです。ほとんどのエンドユーザーについて考えると、これはどれほど簡単でしょうか？
あなたは今問題を見ることができますか？
エンドユーザーがMY証明書を受け入れると、その時点から接続を所有し、すべてのデータが私のマシンを通過します。
基本的に何が起こるかというと、これはあなたが自分の証明書に自己署名しているので、それが有効であることを証明する方法がありません。したがって、トラフィックは問題なく暗号化されますが、それが自分のものであることを証明することはできません。ハッカーがサイトとユーザーのコンピューターの間を行き来してトラフィックを傍受できる場合、ハッカーはトラフィックを復号化して何が起こっているかを読み取ることができます。 （彼はまた、あなたと同様のドメイン名を登録し、タイプミスを待つか、あなたではなく彼のサイトにそれらを導く電子メールを送信して送信することでこれを行うことができます）
User ****** Hacker **** Your website
彼がこれを行うことができる理由は、彼が自己署名証明書も提示できるからです。次に、ユーザーは実際にはあなたではなくハッカーと通信しています。ユーザーには違いがわかりません。実際、ハッカーが必要な場合は、トラフィックを再暗号化してサイトに送り返し、ユーザーの資格情報を使用してサイトとの独自の通信ストリームを開始できます。または、トラフィックが前後に移動するのをはっきりと見てください。
彼がトラフィックを変更できるわけではありません。これは、SSLハンドシェイクが暗号化されずに開始され、サーバーがクライアントがその時点から使用するためのSSL証明書を送信することです。攻撃者が最初からそこにいる場合は、この最初の証明書を自分の証明書に置き換えてから、サーバーが送信した証明書を使用してサーバーとの間のトラフィックを暗号化/復号化し、自分の証明書を使用して攻撃者に送信します。
証明書が認証局によって署名されている場合、CAによっても署名されている偽の証明書と置き換えるのは少し難しいです。ただし、攻撃者はこの証明書を自己署名証明書に簡単に置き換えることができるため、警告が表示されます。
証明書を検証する際に考慮すべき2つのポイントがあります。
- 信頼できるエンティティによって発行されたことを確認し、
- 接続しようとしているサーバーのIDと一致することを確認します。
CA発行の証明書
X.509証明書仕様を使用する公開鍵インフラストラクチャ は、このために配置する構造を定義します。これは、ツリーを取得する階層モデルであり、そのルートは認証局（CA）であり、そのリーフはエンドエンティティ証明書（特にサーバー証明書）です。
ルートCA証明書は、自己署名される傾向があります。それらの束は、OSまたはブラウザにデフォルトで含まれています。これが「信頼の飛躍」の部分であり、OS /ブラウザベンダーがCAが適切に仕事をすることを精査したことを信頼します。大きな商用CAには、Verisign、Thawteなどがあります...
その後、CAは他の証明書に署名する場合があります。信頼できるCAによって署名されているかどうかを確認することで、これまでに見たことのない証明書を確認できます。中間CAも存在する可能性があります。たとえば、https://www.google.com/の証明書は "Thawte SGC CA"によって署名されており、それ自体は "VeriSign、Inc。/ Class 3 Public Primary Certification Authority "（ここでは簡略化のために名前を短くしています）。 CAの仕事は、証明書を発行する個人/機関がそのホスト名の正当な所有者であることを（PKIの外部で）確認することです（例：ここではwww.google.com）。この帯域外検証の違いは、EV以外の証明書の場合、ドメイン名を登録したアドレス（whoisディレクトリにあります）に電子メールを送信するだけで行われることがよくあります。 。
これが完了したら、https://www.google.com/を信頼するかどうかわからないとします。クライアントは、この証明書を、所有しているトラストアンカー（CA、多くの場合、OS /ブラウザーベンダーによって事前にインポートされている）に対して検証します。 www.google.comに接続すると、ブラウザは証明書を取得し、信頼できる発行者（この場合は、 Verisignから1つ）。これまでのところ、証明書は信頼されています。 2番目のステップは、この証明書が実際にこのマシン用であることを確認することです。 HTTPSの場合、これは、ホスト名が証明書のサブジェクト代替名拡張子にあることを確認するか、フォールバックとして、サブジェクト識別名の「共通名」（CN）エントリにあることを確認することによって行われます。これは RFC 2818（サーバーID） で説明されています。
ここで考えられる攻撃の試みは次のとおりです。
- 攻撃者は、独自のCAを使用して（そのホスト名用かどうかに関係なく）証明書を偽造します。それらのCAはブラウザによって認識されないため、証明書は検証されません。発行者名を偽造したとしても、署名を偽造することはできません（既に信頼しているCA証明書を使用して公開鍵を使用して検証するため）。ここでの最大の問題の1つは、シグニチャの強度にありました。衝突攻撃はMD5ダイジェストアルゴリズムを使用して実証されているため、CAは代わりにSHA-1を使用します。これは、より堅牢であると考えられています。 RSAwithSHA1またはDSAwithSHA1が十分に堅牢であると考えている場合は、問題はありません。
- 攻撃者は、よく知られているCAから正当な証明書を取得しますが、ホスト名は異なります（CAが他の誰かに発行してはならないため）。彼らが
www.example.comを取得したとしましょう。www.google.comに接続しようとすると、トラフィックがボックスにリダイレクトされます。ボックスには、信頼できるCAによって検証可能な証明書が表示されますが、www.example.comの場合です。ここで、ホスト名の検証が重要になります。ブラウザは、意図したホストに接続していないことを警告します。
このシステムは、MITMがトラフィックをマシンにリダイレクトした場合に、クライアントが接続を受け入れないようにするように設計されています。もちろん、これは、ユーザーがブラウザに表示される警告を無視しない場合にのみ有効です。
自己署名証明書
あなたがCAであり、この自己署名証明書が直接サーバー証明書である可能性があることを除いて、これは同じ原則です。独自の自己署名証明書を作成してマシンに配置する場合は、信頼できる機関としてブラウザにインポートすることもできます。その場合は、上記と同じ手順に従います。
Firefoxなどの一部のブラウザでは、これらのルールに永続的な例外を追加できます。接続するマシンの証明書が何であるかを他の方法（管理者が直接証明書を提供したなど）でわかっている場合は、署名されていなくても、明示的に信頼することを選択できます。信頼できるCA、または名前が一致しない場合。もちろん、このためには、この特定の証明書がどうあるべきかを事前に明示的に知る必要があります。
いずれの場合も、ユーザーが警告を無視することを選択し、信頼されていない証明書を使用した接続へのリダイレクトを受け入れると、MITM（信頼されていない証明書を使用）はトラフィックを確認/リダイレクト/変更できます。