タグ付けされた質問 「man-in-the-middle」

サーバーを再インストールしたところ、次のメッセージが表示されました。 [user@hostname ~]$ ssh root@pong @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the …

619 ssh  verification  ipa  man-in-the-middle 

私はこの問題に関連するたくさんのドキュメントを読みましたが、まだすべてをまとめることができないので、いくつか質問します。 まず、私が理解している認証手順について簡単に説明します。これについては誤解されているかもしれません。クライアントが接続を開始し、サーバーがそれに応答して公開鍵、メタデータ、およびデジタル署名の組み合わせで応答します。信頼できる機関。次に、クライアントは、サーバーを信頼するかどうかを決定し、ランダムなセッションキーを公開キーで暗号化して送信します。このセッションキーは、サーバーに格納されている秘密キーでのみ復号化できます。サーバーがこれを実行すると、HTTPSセッションが開始されます。 したがって、上記が正しい場合、問題はそのようなシナリオで中間者攻撃がどのように発生するかです。つまり、誰かがサーバー（例：www.server.com）の応答を公開キーで傍受し、自分がwww.server.comであると思わせる何らかの手段があっても、私のキーを解読することはできません。秘密鍵なし。 相互認証について言えば、それはすべてクライアントIDに関するサーバーの信頼に関するものですか？つまり、クライアントはすでに適切なサーバーと通信していることを確認できますが、サーバーはクライアントが誰であるかを知りたがっています。 そして最後の質問は、相互認証に代わるものです。上記の状況でクライアントとして機能する場合、SSLセッションの確立後にHTTPヘッダーでログイン/パスワードを送信するとどうなりますか？ご覧のとおり、接続は既にセキュリティで保護されており、サーバーはこの情報を使用して識別できるため、この情報を傍受することはできません。私が間違っている？相互認証と比較したこのようなアプローチの欠点は何ですか（実装の複雑さではなく、セキュリティの問題のみが重要です）？

91 security  ssl  man-in-the-middle