見えるセキュリティ
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は比較の基準を作るためのもので、中間者攻撃そのものの詳細は「中間者攻撃の基本」で扱っています。
- 現在のSTEP
Browser
Webリクエストを送る
持ち物
- POST /profile nickname=Blue
- 現在のSTEP
Attacker
HTTP通信を受け取り、確認・変更する
持ち物
- POST /profile nickname=Blue
Server
HTTPリクエストを受け取る
持ち物
—
1. BrowserがHTTPリクエストを送る
Browserは暗号学的に保護されていないHTTPでServerへリクエストを送ります。ここではプロフィールの表示名をBlueへ変更するリクエストを例にします。
技術的な詳細を見る
この教材では、TLSなどによる通信路の保護や、Application側での追加の暗号学的保護がないHTTP通信を例にしています。
STEP 1 / 4: BrowserがHTTPリクエストを送る
この概念の要点
注意
HTTP通信そのものは通信路を暗号学的に保護しない
今回の例では、経路上のAttackerがHTTPリクエストの内容を確認し、Serverへ届く前に変更できます。
要点
次のLensでもAttackerの位置は変わらない
TLSを使用してもAttackerが通信経路から消えるわけではありません。次のLensでは、同じBrowser・Attacker・Serverの配置のまま、TLSによって何が変わるのかを確認します。
理解確認
参考資料
- RFCRFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3
RFC 9846TLS 1.3の認証・機密性・完全性とApplication Data保護を定める仕様
- RFCRFC 9525: Service Identity in TLS
RFC 9525TLSでClientが接続先Serverのidentityを確認するための仕様