web-dev-qa-db-ja.com

安全な接続を使用しているときにMiTM攻撃を実行できないのはなぜですか

私を悩ませているこのばかげた質問があります。安全な接続（HTTPなど）を使用していない場合、Cookieが傍受され、IDとパスワードを持っているかのようにサイトに接続するために使用されます。安全な接続（https）を使用することで、これを防ぐことができます。これにより、サーバーに送信されるCookieが確実に暗号化されます。

私の質問は、なぜ攻撃者は暗号化されたCookieを使用できないのですか？攻撃者はこれらのCookieを傍受してサーバーに送信することができますか？

tlshttpman-in-the-middlecookies
6
Hunsu

攻撃者が暗号化されたCookieを使用できない理由は、HTTPSがCookieだけでなく、クライアントとサーバー間のHTTP通信全体を暗号化するためです。 （攻撃者がプロトコルの主要な交換部分を破壊できなかった場合を除いて、それは別の質問の話です。）

楽しい演習として、Wiresharkとブラウザーのデバッガーの両方を使用して、お気に入りのHTTPSサイトにアクセスしたときのネットワークトラフィックを監視します。

9
PlasmaSauna

Cookieを見つけることができないため、また、できたとしても、Cookieを再利用することはできません。

実際のHTTPリクエストは次のようになり、全体が暗号化されます。

GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Accept: text/html,application/xhtml+xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36 OPR/18.0.1284.49
Referer: http://en.wikipedia.org/wiki/Main_Page
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: centralnotice_bucket=0-4.2; uls-previous-languages=%5B%22en%22%5D
Connection: keep-alive

クッキーは他のたくさんのものと混ぜられることに注意してください。暗号化されたcookieを見つけることができないため、暗号化されたcookieを取得することはできません（ブラウザーごとに、要求ごとに異なるものに囲まれています）。見つけることができたとしても、SSLには攻撃者がリクエストを再送信することを防ぐための手段（ リプレイ攻撃 ）が含まれ、 メッセージ認証コード （MAC）が含まれます攻撃者がリクエストをスライスしてその一部のみを使用するのを防ぐため。

さらに、SSLは接続ごとに異なる暗号化キーを使用します。暗号化されたCookieを取得してMACをバイパスできたとしても、それらを使用するには間違ったキーで暗号化されていることがわかります。

10
Mark

たとえば、誰かがブラウザや人事部から直接データを取得できるようにして（おそらく、立ち上がって離れたときにコンピュータの前に座って）、誰かがCookieを取得できれば、間違いなくCookieとそれを再利用できます。うまくいくでしょう。

Httpsはhttpパケット全体を暗号化し、cookieはパケットの一部として送信されるため、攻撃者はcookieを見ることができません。

ちなみに、攻撃者が使用できる別の方法は、ブラウザーをだましてhttp経由でサーバーにcookieを送信させることです。 （攻撃の詳細に興味がある場合は、Google sslstrip）。このサーバーを防止するために、ブラウザに安全なSSL接続でのみCookieを送信するように指示する「安全な」フラグでCookieをマークできます。

0
PopularIsn'tRight