見えるセキュリティ

Web通信の中間者攻撃とTLS

WEB MITM & TLS

この概念とは?

Web通信では、暗号学的に保護されていないHTTP通信をAttackerが通信経路上で受け取れる場合、通信内容を読まれたり、途中で改ざんされたりする可能性があります。一方、TLSを正しく確立した通信では、Serverの認証と通信内容の暗号化・完全性保護によって、経路上のAttackerからApplication Dataを保護します。この教材では、同じようにAttackerが通信経路上にいる状態で、TLSの有無によって何が変わるのかを比較します。

TLSは、Attackerを通信経路から取り除く仕組みではありません。正しいServerとのTLS通信が確立されると、BrowserとServerの間でやり取りするApplication Dataは暗号化・認証されます。そのためAttackerは通信を中継・遮断したり暗号化されたデータを観測したりできますが、HTTPの内容を読んだり、変更したデータを正しい通信として検出されずに受け入れさせたりすることはできません。

THEME
network
KIND
attack
REVIEW
self-reviewed ·

暗号学的に保護されていないHTTPリクエストをAttackerが確認・変更して中継する流れ

前の教材で確認した中間者攻撃を、WebのHTTP通信に置き換えて確認します。このLensは比較の基準を作るためのもので、中間者攻撃そのものの詳細は「中間者攻撃の基本」で扱っています。

  • Browser

    Webリクエストを送る

    現在のSTEP

    持ち物

    • POST /profile nickname=Blue
  • Attacker

    HTTP通信を受け取り、確認・変更する

    現在のSTEP

    持ち物

    • POST /profile nickname=Blue
  • Server

    HTTPリクエストを受け取る

    持ち物

STEP 01 / 04DERIVE · MOVE

1. BrowserがHTTPリクエストを送る

Browserは暗号学的に保護されていないHTTPでServerへリクエストを送ります。ここではプロフィールの表示名をBlueへ変更するリクエストを例にします。

技術的な詳細を見る

この教材では、TLSなどによる通信路の保護や、Application側での追加の暗号学的保護がないHTTP通信を例にしています。

STEP 1 / 4: BrowserがHTTPリクエストを送る

現在のSTEP 1STEP 2STEP 3STEP 4

この概念の要点

  • 注意

    HTTP通信そのものは通信路を暗号学的に保護しない

    今回の例では、経路上のAttackerがHTTPリクエストの内容を確認し、Serverへ届く前に変更できます。

  • 要点

    次のLensでもAttackerの位置は変わらない

    TLSを使用してもAttackerが通信経路から消えるわけではありません。次のLensでは、同じBrowser・Attacker・Serverの配置のまま、TLSによって何が変わるのかを確認します。

理解確認

今回のHTTP通信で、経路上のAttackerが行えたこととして最も適切なものはどれですか?

参考資料

RELATED CONCEPTS