I-Dを読む。#1 Captive Portal Problem Statement
もう何回も読んでるI-Dだけどブログで改めてまとめてみる。
I-D : Captive Portal Problem Statement(draft-nottingham-capport-problem-01)
Author : M.Nottingham(Akamai)
この方はIETFだけでなくW3C界隈などでも非常に有名。HTTP WGで活発に活動されている方で、Captive Portalのためのステータスコード511の提案をしたお方でもあります。最近はQUIC WGが忙しいようでcapportにはあまり顔を出してくれない。。orz
タイトルは”Captive Portal Problem Statement”なんてかっこいい横文字を書きましたが、つまりcapport WGにて「Captive Portalの問題点はどう定義されてるの？」って話をします。 前置き的な話はこちらやこちらでしています。
実は私が以前IETF報告会で発表した資料もありまして、今回の内容はそれと被りますのでご了承を。
0 : 問題の概要
まずCaptive Portalで、一番問題とされているのが、ユーザーの通信に割り込み認証ページに強制的に誘導することです。実質ブラウザのHTTPセッションを横取りし、強制的にWebページにリダイレクトさせるという挙動はMan-in-the-middle-attack(MITM/中間者攻撃)と大差がなく、ユーザーエクスペリエンスが損なわれると言えます。
そこでcapport WGの目的は以下のようになっています。
- Captive Portalとユーザーデバイスのブラウザ間とのやりとりをシンプルにする
- できるだけCaptive Portalと人とのやりとりを少なくする(やりとりが多くなるとユーザーにとって混乱の原因となるから)
1 : 現在定義されている問題点
-
False Negatives(偽陰性) : Captive Portalの検知にはOSによって様々な方法が使われているが、検知に失敗することがよくある。その場合、Captive Portalがあるにも関わらず、OSのブラウザは今接続しているネットワークがOpenなネットワークだと捉えてしまうため、そもそもCaptive Portalにアクセスできない
- Longevity(コネクションのタイムアウト) : 大抵のCaptive Portalには「1回30分、1日3回まで」とアクセス回数や時間の制限がついていることが多い。作業途中であっても突然タイムアウトになってしまい、一度ネットワーク接続は切断され、ネットワークに再度ログインしなければならない。
- Interoerability Issue(相互接続性) : Captive Portalは特定のOSやブラウザの性能や挙動に依存することがある。しかし、各OSやブラウザ間でそういった挙動の共有等はされていないため、特定のOSでは検知されるが、他のOSでは検知されない、といった挙動の違いが出てしまう。
- Confusion(混乱) : Captive Portalの挙動は中間者攻撃と大差ないため、ユーザーやユーザーエージェントを混乱させることがある。
- TLS : Captive PortalがTLSセッション(HTTPSやIMAPS等)に割り込もうとすると、証明書エラーが発生してしまう。このようなエラーの許諾をクリックしてしまうという悪い習慣をユーザーにつけてしまう。
- Unexpected Configuration(予想外の設定) : クライアント側でCaptive Portalにとって予想外な設定(固定IPアドレス/DNSサーバー/HTTPプロキシ等)をしていた場合、正しく動かない場合がある。例えば、通常Captive Portalでは、DNSサーバーはDHCPを用いて動的に設定されることが予想されているが、あらかじめクライアント側で特定のサーバーを静的に指定していた場合は動かないことがある。
- Stealing Access(なりすまし) : Captive Portalのようなオープンなネットワークでは安全なネットワークを設定することが難しい。このような安全な通信が保証されていない状況下で攻撃者が認可されたユーザーのフリをすることも可能である。(Captive PortalはユーザーのMACアドレスをひも付けて認証することがあるため)
- Connectivity Interruption(接続中断) : CelluarとWi-Fiなど複数のネットワークインタフェースを持つデバイスの場合、片方がCaptive Portalのネットワークに繋ぐため、もう片方のインタフェースを落としてしまうことがある。この場合、Captive Portal Login Processを終えるまでインターネットへの接続が得られない。
これに補足、というわけではないのですが、スマートフォンブラウザでCaptive Portalが認証なしでインターネットへの接続が成功してしまうといった問題のある挙動も観測されています。
2 : Captive Portal Detectionによって生じる問題点
-
False Positives(偽陽性) :ログインするためにWebブラウザを用いないネットワークもあり、ネットワークにアクセスするためにVPNが必要となるケースがある。この場合、現在主流となっている、HTTP redirectionに依存したCaptive Portalの検知は逆効果である。
- Non-Internet Networks(非インターネットネットワーク) : 社内ネットワークのような外に出ることがでいない非インターネットネットワークの場合、ユーザーデバイスにCaptive Portalの認証を通過したことを知らせる術がない。よって、認証・認可されたとしてもインターネットに接続できない状況が続いてしまう。
- Sandboxing(サンドボックス) : Captive Portalを検知した際に、サンドボックス化されたブラウザで開くOSもある(Captive Portal Detection)。これはユーザーのプライバシーを保護するための機能でもあるが、実際この環境下では以下のような問題もある。(通常のブラウザとは別に開かれるこんな画面↓)
- APIへの限られたアクセス
- 完全に孤立したブラウザのため、ユーザーがステートを持つことができない
- Captitve Portalは様々なプラットフォーム上でアドホックに実装されているため、挙動にバラツキがある。
- 上記のようなUXを損なう問題を避けるために、Captive Portalのオペレーター側が、Captive Portal Detectionを回避するようCaptive Portalに設定することもある。
3 : Captive Portal Detectionを回避することで起こる問題
- Captive Portal Detectionを回避することでSection 2にあるような問題を起こしてしまう・・・というようににわたま問題感があります。例えば、回避の方法として、Captive Portalの設定で、検知に使用されるURLをCaptive Network下でもアクセス可能なホワイトリストに入れておくという手法があります。しかし、これはOSにとってCaptive Portalをオープンなネットワークだと認識させてしまうので、Section 2のFalse Negativesのような問題にもなってしまうのです。
