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