SSH設計者は、中間者攻撃に非常に気を配っていたようです。
彼らのアプローチは、サーバーに初めて接続したときにサーバーの公開鍵の指紋を保存することでした（たとえば、ユーザーがウイルスに感染している場合など、初めて汚染されたネットワークからユーザーが接続しないことを願っています）。コンピューター）。ユーザーは次にこのサーバーに接続するときに、フィンガープリントを使用してサーバーの公開鍵を検証します。
実際には、多くのユーザーが指紋の不一致に関する警告を単に無視し、サーバーの再インストールが原因であると想定していることがわかりました。MITM 攻撃は実行が非常に難しく、まれであるため、心配する必要はありません。さらに、多くの場合、ユーザーは多くの異なるコンピューターを ssh で使用したいと考えており、使用SSHしたいコンピューターにすべてのフィンガープリントをインポートすることを気にしません (ねえ、私のサイトがダウンしている理由がわかりますか? 私はパニックに陥っています!オフィスにいないので、最寄りのインターネット カフェに行って見てみます）。
公平を期すために、サーバーを として使用DNSSECおよび使用できます。しかし、実際に使用されているのを見たことはありません。とにかく、それはプロトコルの必須部分ではありません。DNSCA
何年もの間、事前共有秘密がなければ MITM を回避できないと思っていましたが、最近 Bruce Schneir の優れた "Practical Cryptography" を読んでいて、彼はインターロック プロトコルについて言及しています。
- Alice は Bob に自分の公開鍵を送信します。
- Bob は Alice に自分の公開鍵を送信します。
- Alice は、Bob の公開鍵を使用してメッセージを暗号化します。彼女は、暗号化されたメッセージの半分をボブに送信します。
- ボブは、アリスの公開鍵を使用してメッセージを暗号化します。彼は暗号化されたメッセージの半分を Alice に送信します。
- Alice は、暗号化されたメッセージの残りの半分を Bob に送信します。
- ボブは、アリスのメッセージの 2 つの半分をまとめて、自分の秘密鍵で復号化します。ボブは、暗号化されたメッセージの残りの半分をアリスに送信します。
- Alice は、Bob のメッセージの 2 つの半分をまとめて、彼女の秘密鍵で復号化します。
ここで、マロリーはプロトコルのステップ (3) でアリスのメッセージの半分を受信した後、ボブに何かを送信する必要があります。彼はボブへのメッセージを捏造しなければなりません。ボブは自分が捏造していることに気付くでしょうls。
SSHなぜそのようなスキームを使用しなかったのですか？それは本当にその目標に合っているようです。他のエンティティを必要とせず、MITM 攻撃を大幅に困難にします。
それは固有のものですか？問題の理解に欠陥がありますか? それとも設計者が、追加のセキュリティはプロトコルを複雑にする価値がないと考えただけですか?
PS:
オーバーヘッドが大きすぎると思われる場合は、プロトコルのユーザーに10K、接続内の最初のデータにのみインターロックを使用するように強制することができます。したがって、実際にはそれほど問題にはなりませんが、MITM はより多くなります。とてつもなく難しい。
更新:ここで 説明されているインターロック プロトコルに対する攻撃は、MITM 攻撃が可能であることを意味するものではありません。通信中に単一のパスワードが送信された場合、MITM がそれを傍受でき、ユーザーにはタイムアウト エラーのみが表示されることを意味します。
更新 2:
ポイント Eugene、レイズは有効です。インターロック プロトコルは認証を許可しません。つまり、 に接続している場合example.com、それが実際example.comに であり、 にmalicious.comなりすましていないことをまだ確認できませんexample.com。たとえば、 がなければ、それを確実に知ることはできませんDNSSEC。したがって、たとえば、SSHミサイル サイロにアクセスして書き込みを行った場合launch_missile -time now(たとえば、サーバーが実際にミサイル サイロのサーバーであることを確認するために使用せずにls)、実際には悪意のあるサーバーでそれを書いた可能性があります。敵は、あなたが敵に対してミサイルを発射しようとしていることを知っています。このタイプの攻撃は、実際にはインターロック プロトコルでは防げません。
しかし、プロトコルを正しく理解していれば、はるかに危険な攻撃、非常に実際的な攻撃を防げる可能性があります。インターロック プロトコルを使用すると、 について何も知らなくても、サーバーにアクセスexample.comすることは不可能でSSHあり、誰かがSSHセッション全体を盗聴する可能性があります。このタイプの攻撃の可能性ははるかに高いと思います。
たぶんSSH、MITM 攻撃を気にしませんか? 私はそうは思いません。たとえば、Putty FAQを参照してください。
これらの煩わしいホスト キー プロンプトは、SSH の要点です。それらがなければ、セッションを保護するために SSH が使用するすべての暗号化技術は、攻撃者の仕事を少し難しくするだけです。攻撃者は、ユーザーとサーバーの間にパケット スニファーを配置するのではなく、実際にルーターを破壊し、やり取りするパケットの変更を開始する必要があります。しかし、それは単にスニッフィングするよりも難しいことではありません。ホストキーのチェックがなければ、クライアントまたはサーバーによって完全に検出されなくなります。
彼は明らかに MITM 攻撃について話しているのであって、サーバー認証についてではありません。インターロック プロトコルを使用すると、Putty FAQ に記載されている攻撃を明確に防ぐことができると思いますが、なぜ使用しなかったのかはまだわかりません。