読者です 読者をやめる 読者になる 読者になる

にたまご。

チーズとたまごとパンもすき。

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の挙動は中間者攻撃と大差ないため、ユーザーやユーザーエージェントを混乱させることがある。
  • DNS/DNSSEC : Captive PortalDNSリクエストが偽装された場合 、DNSゾルバ、DNSSECリゾルバやアプリケーションを混乱させる。
  • TLS : Captive PortalTLSセッション(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の認証を通過したことを知らせる術がない。よって、認証・認可されたとしてもインターネットに接続できない状況が続いてしまう。

   f:id:ao0780:20170221093136p:plain

  • Sandboxing(サンドボックス) : Captive Portalを検知した際に、サンドボックス化されたブラウザで開くOSもある(Captive Portal Detection)。これはユーザーのプライバシーを保護するための機能でもあるが、実際この環境下では以下のような問題もある。(通常のブラウザとは別に開かれるこんな画面↓)

 

   f:id:ao0780:20170221093325p:plain  

  1. APIへの限られたアクセス
  2. 完全に孤立したブラウザのため、ユーザーがステートを持つことができない
  3. Captitve Portalは様々なプラットフォーム上でアドホックに実装されているため、挙動にバラツキがある。
  4. 上記のような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のような問題にもなってしまうのです。

 

 

Captive Portal Detectionについて

今回はCaptive Portal Detection(キャプティブポータル検知)についてお話しします。

手っ取り早く言うと、コレ↓ですね。こんな画面見たことあるでしょうか?

f:id:ao0780:20170221093325p:plain    f:id:ao0780:20170211104257p:plain

 公衆無線LANに接続すると、ブラウザが突然開かれるアレです。海外だと、「pop-up window」や「splash window」などと呼ばれています。

Captive Portal Detectionとは

ユーザー保護の目的でOSに実装されている仕組み。通常のブラウザとは別にその場限りのincognito modeなウィンドウで開かれる。incognito modeで開かれることによって、ユーザーが普段使っているブラウザのセッションやクッキーの情報が漏れる心配がない。

各OSのCaptive Portal Detection方法

では、実際にどのようにCaptive Portalを検知するのでしょうか?

基本的には、それぞれのOSには「Well-Known Web Page」と呼ばれる、インターネットアクセスの有無を検証するためのWeb Pageを用意しており、そこへのアクセスがあるかないかでCaptive Portalがあるかどうかを検知します。Captive Portalが検知され、レスポンスとして返ってきた302 redirection urlをfetchし、ユーザーを認証ページに誘導します。

 

各OSにはCaptive Portal Detection Strategyという検知のための手法があり、以下の表の通りです。

f:id:ao0780:20170221100614p:plain

  •  iOS/macOS : メカニズムは非常に単純。「Success」というレスポンスが返ってくる、captive.apple.comなどのWell-Know Web Pageにアクセスし、「Success」が得られない場合はCaptive Portalと検知している(タイムアウトは除く)。
  • Windows :  Windowsには2段階の判断ある。まず、dns.msftncsi.comにDNS lookupし、IPアドレスをチェックする。これはCaptive Portalがあるのか、またはそもそもネットワークの接続性の問題のため、インターネットアクセスが得られないのかを判断するためである。そして、http://www.msftncsi.com/ncsi.txtにリクエストを送り、「Microsoft NCSI」というレスポンスが得られなかった場合、Captive Portalと見なされる。
  • Android : AndroidはHTTP/HTTPS両方の接続を確かめるページを用意しているが、Captive Portalの特性上HTTPS Probeはほぼ失敗してしまう。HTTP Probeを確認する場合、http://google.com/gen_204にアクセスする。このWebページは、インターネットアクセスがある時に204 & No Contentを返す。Androidは公衆無線LANに接続すると、まずこのページへのアクセスをチェックし、「204 & No Content」以外のレスポンスを得た場合Captive Portalだと認識する。
*Android7.0からの変更点

上記のAndroidの説明を見て、HTTP/HTTPS両方確認する必要はないと思った方もいると思いますが、Android7.0からは、

  •  HTTPS probeがSuccessしなかった場合、自動的にそのネットワークに接続しない。
  • ユーザーが自分で使うかどうか「Manual」に選択する。

というように変更されたので、一応意味はあるっぽいです。従来はCaptive Portalを検知すると、自動的にincognito windowで開くというメカニズムでしたが。しかし、そもそもユーザーを安全ではないネットワークに自動的に接続させるのはいかがなものか、とGoogleは考え上記のようにポリシーの改定を行ったみたいです。

 

AndroidのCaptive Portal Detectionは他にもいろいろと細かく設定がされており、複雑ですが、興味のある方はここからソースを読んでみてもおもしろいかもしれません。「204」と「No Content」両方チェックしている理由なんかも記されています。700行目前後から読むのがオススメだとか(by Googler)。

 

Captive Portalって何?

Captive Portalとは

「キャプティブポータル」と読みます。

某コーヒーショップや空港などの無線LAN認証時によく見かけるコレです。

 

f:id:ao0780:20170211104257p:plain


ユーザーのブラウザのHTTPセッションを横取りして、特定のWebページ(だいたい認証や同意ページ、時々課金など)に強制的に誘導する仕組みです。
無線LANのユーザーのアクセスコントロールによく使われています。

 

具体的な挙動としては、

  1. 自分のデバイスでSSIDを選択
  2. Wi-Fiネットワークに接続
  3. ブラウザを開いて、適当にapple.comとかを検索すると認証ページにリダイレクトされます。
  4. メールアドレスを登録したり、SNSOAuth認証する
  5. 完全なインターネットコネクションを得ることができます。

 

f:id:ao0780:20170211112210p:plain

 

自分は、このCaptive Portalの一連の流れを ”Captive Portal Login Process”と勝手に名前をつけて呼んでいます。基本的にこのプロセスを全て終えないと、自由にインターネットを使うことができません。 

 

ちなみに3の時点では限られたWebページやドメイン下にしかアクセスできません。

例えば、一番有名なオープンソースのCaptive Portal 「Coova Chilli」ではFacebookのアカウントで認証させたい時はそのドメインへのアクセスはホワイトリストに入れ、アクセス可能にしたり...といった設定が可能です。(ただ、これは一例でそれぞれの仕様によると思います)

 

一般的に広く使われているCaptive Portalですが、実は「様々な技術を無理やり詰め合わせた」みたいなものなので、実装や設計に問題があり、ユーザービリティやセキュリティに悪影響を与えることも多いと言われています。実際、Captive Portalを排除しようという動きもあり、そういったコミュニティが次世代ホットスポットとしてNext Generation Hotspot(NGH)を提案したりしています。

 

しかし、Captive Portalは広告やユーザーの情報を得ることができるというマーケティング的な役割も持っているため、ビジネス界としてはまだまだ手放したくないようです。

 

最近では、インターネット技術の任意標準化団体のIETFで、Captive Portalのユーザーインテラクションを改善するためのワーキンググループ capport WG が作られ、議論が行われています。興味のある人はチラ見してみるといいかも。

Captive Portal Interaction (capport) -

 

具体的なCaptive Portalの問題点は次回触れたいと思います。

 

今日はここまで\(・-・)/