dsniffとhttpsniffing

dsniffとhttpsniffing

コマンドを実行しdsniff -i eth0、新しいターミナルウィンドウを開き、FTPサーバーを試みると、接続して終了します。 dsniff はユーザー名とパスワードを返します。

google.comや他のウェブサービスで同じことを試しても、dsniffはパスとユーザー名を報告しません。

なぜこれですか?私が使用しているウェブサイトはこの種の攻撃に免疫されていますか?私はHTTPサービスについて好意的な意見を持っていません。私はローカルホストで使用していますが、テスト目的でarpspoofingが必要ないと思いますか?

答え1

dsniffを使用すると、認証を含むサイトを開発するときに通信を暗号化するためにTLSを使用する必要がある理由を正確に知ることができます。

暗号化層は、「保護された」トンネル内のHTTPプロトコルの内部動作を実際に難読化し、暗号化されdsniffていないストリームを取得する方法はありません。通常の状況では

詳細については、セキュリティ/スタック交換にTLSリンクと回答を残しておきます。

https://security.stackexchange.com/questions/110914/https-is-able-to-prevent-arp-poison-attack-in-lan

~からhttps://en.wikipedia.org/wiki/Transport_Layer_Security

送信されたデータの暗号化には対称暗号化が使用されるため、接続はプライベートです。この対称暗号化の鍵は、接続ごとに一意に生成され、セッションの開始時にネゴシエートされた秘密に基づいています(ハンドシェイクプロトコルを参照)。サーバーとクライアントは、最初のデータバイトを送信する前に使用する暗号化アルゴリズムと暗号化キーの詳細に同意します(アルゴリズムを参照)。共有秘密の交渉は安全であり(攻撃者が接続中であっても盗聴者は交渉された秘密を取得できません)、信頼できます(攻撃者が盗まれない限り、交渉プロセス中に通信を変更することはできません)。検出された)。通信当事者の身元は、公開鍵暗号化を使用して確認することができます。この認証はオプションですが、通常、少なくとも1人の当事者(通常はサーバー)が要求します。送信されるすべてのメッセージには、転送中に検出されずにデータが失われたり変更されたりするのを防ぐためにメッセージ認証コードを使用するメッセージ整合性チェックが含まれているため、接続は安定しています。

関連情報